Re: Please sync org.apache.ws ...
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-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MRM-74) Browse web user interface
[ 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/browse/MRM-74 > Project: Maven Repository Manager > Type: Task > Components: web application > Versions: 1.0-alpha-1 > Reporter: John Tolentino > Assignee: nick gonzalez > Attachments: maven-repository-webapp-MRM-74.diff > > Original Estimate: 1 day, 16 hours > Remaining: 1 day, 16 hours > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MRM-74) Browse web user interface
[ 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.codehaus.org/browse/MRM-74 > Project: Maven Repository Manager > Type: Task > Components: web application > Versions: 1.0-alpha-1 > Reporter: John Tolentino > Assignee: nick gonzalez > > Original Estimate: 1 day, 16 hours > Remaining: 1 day, 16 hours > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] adding pre/post phases for all major lifecycle phases
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 profiles last, > executions are in pom declared order within a phase). This is possibly > limited. I think one of our items for 2.1 was to make this easier to > specify and possibly order. But I'm worried about jumping in and out of > things in different POMs within a phase. It seems wrong. Just for feedback's sake: so far this worked perfectly for my case without any thought about it. So I think any solution needs to be equally as good at working without custom configuration. Even though it worked, I was very unsure about whether it would, and wasn't confident in it. Is there detailed documentation on the current ordering anywhere? -- Stephen Duncan Jr www.stephenduncanjr.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-2085) POM documentation for repository structure looks out of date
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
Reporter: Howard M. Lewis Ship
The POM documentation, at http://maven.apache.org/maven-model/maven.htm, is out
of date w.r.t the structure of the remote repository.
This element describes all of the dependencies associated with a
project. Each dependency is described by a
dependency element, which is then described by
additional elements (described below).
These dependencies are used to construct a classpath for your
project during the build process.
Maven can automatically download these dependencies from a
remote
repository.
The filename that Maven downloads from the repository is
artifactId-version.jar where artifactId
corresponds to the artifactId element and
version corresponds to the version
element.
When Maven goes looking for a dependency in the remote
repository,
it uses the dependency element to construct the URL to download
from. This URL is defined as:
${repo}/${groupId}/${type}s/${artifactId}-${version}.${type}
Where
repo
is the remote repository URL specified by
${maven.repo.remote}
groupId
is taken from the dependency element
type
is taken from the dependency element
artifactId
is taken from the dependency element
version
is taken from the dependency element
For Maven 2, this looks very different. Looks like the docs were copied from
Maven 1?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] adding pre/post phases for all major lifecycle phases
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 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 phase at the moment. For now it > > seems to work due to luck/pom ordering. > > > I won't go into them here, but prerequisites had a number of issues in > Maven 1.x, and was part of the reason we moved to the lifecycle of m2. > The original m2 had pre/post goals and prereqs. I'd expect you'd find > more about this in the archives. > > I still believe the lifecycle concept is solid and have posted some more > detailed thoughts in another mail. > > Thanks, > Brett > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Stephen Duncan Jr www.stephenduncanjr.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Please sync org.apache.ws ...
... 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]
Re: [proposal] adding pre/post phases for all major lifecycle phases
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 tasks > that I have attached to the package phase at the moment. For now it > seems to work due to luck/pom ordering. I won't go into them here, but prerequisites had a number of issues in Maven 1.x, and was part of the reason we moved to the lifecycle of m2. The original m2 had pre/post goals and prereqs. I'd expect you'd find more about this in the archives. I still believe the lifecycle concept is solid and have posted some more detailed thoughts in another mail. Thanks, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] adding pre/post phases for all major lifecycle phases
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 filter them or do other resourcy things. Is that a need you have? > - move the generate-resources phase after compilation (as it is not > needed to compile, the only constraint is to have the resource well > placed before testing) I think last time we considered this, there was a reason not to in general, and besides - backwards compatibility rules it out. > - create a new packaging (say axis-api) for axistools which binds the > generate-resource phase between compilation and test This won't work, as a packaging can't define a new lifecycle ordering. Please refer to the other mail, and lets see if we can get this use case working under the 3 points I listed. > Maybe a way to get rid of the phases proliferation is to make > proliferate the packagings. > Therefore, the complexity of the phases are hidden in the > plugins-packaging and not shown in the pom which add the confusion to > the users. > > Is that makes sense ? Yes, I thought that was the whole point of it right now. Doesn't the axis tools bind everything for you? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] adding pre/post phases for all major lifecycle phases
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 details: 1) pre/post is wrong in general, as pre-two = post-one. So we should have one phase between, but there we need an appropriate name. Likely this is something sensible and becomes a new lifecycle phase - just like we have now. Then we later discover that needs pre/post, and so on :) I think this really degrades to prereqs and pre/post goals that we had in m1/pre-alpha m2, which we eliminated for good reasons. 2) Some of this discussion around rearranging the lifecycle defeats the actual purpose of the lifecycle in the first place > 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 > approach anymore. If you have a problem with suppress and augment as you've coined it, I'd suggest your packaging might be too granular. Maybe you need a couple of different packaging types? > Say I have two mojos bound to the package phase, for lack of a better > place. This is a common example picked because I think we are missing the prepare-package phase. > It doesn't seem like a good idea to continue addressing this problem an > issue at a time in successive Maven releases. Actually, I think we should. That means we carefully assess each one and take care in adding it. > I'd like to get this into 2.0.3, since it affects some work I'm doing > for a client. Since you have a workaround, I'd prefer we look at the proper solution for 2.1. I had great reservations about allowing this for integration tests in 2.0.2. Piéroni Raphaël wrote: > can you add a post-compile-generate-resources phase ? sometimes a resource > is generated (wsdl file) after the compile phase. I thought we established this could just be generated directly to the resources target. [MOJO-143] 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 profiles last, executions are in pom declared order within a phase). This is possibly limited. I think one of our items for 2.1 was to make this easier to specify and possibly order. But I'm worried about jumping in and out of things in different POMs within a phase. It seems wrong. John Casey wrote: > I generate a model using Modello, and would like to use my own custom > Antlr grammar to create instances of that model. > > Both should fit in generate-sources, but there's a definite order here. Sorry, don't understand what the order is here (what is "creating an instance of the model"?) > Maybe the solution is to split the project in two, one -model, and > another -parser or something. This is a possible solution we should be considering in some cases, I think. John Casey wrote: > 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. While I don't like this, it might be a useful inclusion. I'd like to see more specific examples - I'm worried that the things being excluded are only doing so because the original mojo over-reached its duties (rather than sensible defaults, it assumed too much about your environment and isn't configurable enough). Ok, to track back over this a bit, there are a few issues: 1) needing to exclude lifecycle phases * I'd prefer not to. I think the packaging may be over reaching or the involved mojos not configurable enough. Would like to see more examples. 2) ordering of lifecycle phases * Do not want to customise the order of *phases*, that defeats the purpose. * It appears sometimes there are multiple iterations of the same phases (the axis example), see below. 3) ordering of goals in phases * we already have this within a pom. We need examples of reasons it needs to be ordered through inheritance (including profiles) in a way that doesn't match the current parent first ordering. * we have scope to improve this in 2.1 as we wanted to reassess at least the declaration of goals. Ok, things you can do to address issues here, some already mentioned: 1) split your project into two things. Sometimes this iterations indicate you are building two different things with a dependency between them 2) introduce a goal in the lifecycle that forks a new lifecycle to do the generate, compile stage, then continue with generate, compile. This is a form of iteration. 3) You can use compound goals to enforce ordering. This is similar to 2 in some ways. I don't think this is too hacky under the current arrangement. 4) We can explici
[maven2 build branches/maven-2.0.x - SUCCESS - checkout] Sat Feb 18 00:30:02 GMT 2006
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-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - checkout] Sat Feb 18 00:00:00 GMT 2006
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 additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] adding pre/post phases for all major lifecycle phases
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 phase at the moment. For now it seems to work due to luck/pom ordering. First, I also run dependency:copy-dependencies. If performRelease=true is set, I run an assembly:assembly with a couple of descriptors. One of those is zipping up the result of copy-dependencies. So this goal has dependency:copy-dependencies as a prerequisite. Then I run assembly:directory with another descriptor to create a directory that contains 1) the result of source:jar and javadoc:jar (done automagically with performRelease=true), and 2) the results of the assembly:assembly descriptor.So this goal should really have three prerequisites: source:jar, javadoc:jar, and assembly:assembly The positive side of looking at this way is that it keeps ordering knowledge de-centralized. It would be analgous to a multi-project build: based on prerequisites, Maven would determine the order to execute the plugins that occur during the same lifecycle phase. The downsides are: how would identify a particular execution as a prerequisite? Would you always know your prerequisites, or just that you should always be last (my assembly:directory actually outputs target/*.jar and target/*.zip, for instance). Also I guess you'd probably end up repeating yourself: I'd have to both specify the prereq on javadoc:jar and source:jar, but also declare them (if they weren't automatically down by having profiles with the same activation property+value). Sorry for thinking on e-paper here, but I'm hoping if I go through the whole thought process, you guys with more experience might be able to take more out of it. Looking at my downsides, I have a more extreme suggestion. Rather than specifying executions, and additionally specifying prerequisites, could you just fully specify the prerequisite as a fully-defined plugin/execution within another execution? If this were allowed to be nested, it could solve at least a fair number of use cases. Does the reactor currently handle build-ordering of nested levels of subprojects? Or would this be a new foray into ordering resolution? Anyhow, just my ideas to toss out. Any thoughts? -Stephen On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: > 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 bindings > can come from: > > 1. packaging lifecycle mapping > 2. parent POM > 3. profiles > 4. POM > 5. (am I missing something?) > > So, any syntax would have to support this layering in a way that > wouldn't be overly confusing. > > FWIW, I think I have a band-aid on my client's project that will work > for the time being. I'd much rather see this stuff fixed correctly soon, > rather than have 10,000 lifecycle phases to support for backward > compatibility later on... > > -john > > Jesse McConnell wrote: > > +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 next layer of > > complexity with some type of ordering maybe.. > > > > Providing a mechansim of strict execution ordering inside of a lifecycle > > phase could address this.. Custom lifecycle phases and goals declared in > > the pom that can be bound by plugins inside of the pom? (icky) Otherwise it > > is just too easy to keep adding on layers of pre and post processing :) > > > > > > my 2cents > > > > -- > > > > to address the axistools pluign, we have discussed this on irc before. it > > is completely reasonable to compile some classes, generate a wsdl off of > > those classes for something like a server side wrapping of webservices and > > then want to generate the client code off of that wsdl.. > > > > but what we decided at the time was that it was also ok to just embed that > > wsdl into the final jar and then in another project process that wsdl out of > > the dependency jar and generate the client code...perhaps that can be > > revisited, but the idea of having to support a compile -> generate sources > > -> compile cycle is not one that has been addressed completely. Especially > > since I have personally written 4 plugins that needed this type of cycle > > already, and just swiped code out of the compiler mojo to do it :P > > > > jesse > > > > > > > > On 2/17/06, Piéroni Raphaël <[EMAIL PROTECTED]> wrote: > >> +1 > >> > >> can you add a po
[jira] Commented: (MJAR-11) extention parametrization
[ 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 is not a real war and the war plugin complains rightfully so about that fact. Nonetheless, because of bonehead 3rd party integration we need to give this jar a ".war" extension. The resulting war will later be uploaded and have it's contents sucked into a real exploded war. Thus, people have real business needs for needing the ability to give ithe artifact a final name. > extention parametrization > - > > Key: MJAR-11 > URL: http://jira.codehaus.org/browse/MJAR-11 > Project: Maven 2.x Jar Plugin > Type: Improvement > Reporter: Dmitry Tsigelnik > > > Please add parametrization of extention of building file. > For example: I want to build ejb3 file or another archive special for > concreate Jboss deployer likes .har or .spring -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-2084) Jar plugin does not respect the authority of the element
[ 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 filename (including an extension, but with no path information) that the produced artifact will be called. The default value is artifactId-version.extension (where extension is derived from type). I'll see about submitting a patch to fix this this weekend. > 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 > Assignee: Brett Porter > > > I have a simple jar plugin with the following build element > > > > org.apache.maven.plugins > maven-compiler-plugin > > 1.5 > 1.5 > > > > foo.jas > > However, when building I get a final artifact with the name 'foo.jas.jar' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-2084) Jar plugin does not respect the authority of the element
[ 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 vote/watch. > 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 > Assignee: Brett Porter > > > I have a simple jar plugin with the following build element > > > > org.apache.maven.plugins > maven-compiler-plugin > > 1.5 > 1.5 > > > > foo.jas > > However, when building I get a final artifact with the name 'foo.jas.jar' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-747) HtmlUnit 1.8 upload request
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 members, including myself: http://htmlunit.sourceforge.net/team-list.html http://sourceforge.net/project/memberlist.php?group_id=47038 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: plugin testing
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 is difficult. We do need a mock
MavenProject instance, and can use PlexusTestCase as the base to be able
to lookup components to set.
Eventually I'd suggest creating a new module with an abstract test case
that extends PlexusTestCase. This can be used to lookup components to
set (and possibly automatically wire them up which would be much more
convenient):
setUp() {
mojo = lookup( Mojo.ROLE, "goal name" );
}
In this case we also need to have an expression evaluator replacement
that will provide replacements for ${project} and ${settings}.
I'd start by manually injecting those values though and see how it goes.
- Brett
Jesse McConnell wrote:
> 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'll jump right to the chase.
>
> We need someway to be able to gather code coverage metrics from plugin
> testing so we have at least a modicum of belief that changes didn't break
> anything, and since plugins can be so amazingly complex in many cases and
> just downright trivial in others there can't be a one size fits all
> solutionso
>
> I propose that we break the problem down into two neat little parts. First
> would be actual plugin unit testing were we have a simple way to
> instantiating the plugin and any of the pretty normal variables that get
> injected, collections, strings, bool, etc. then we have basic junit type
> testing on these objects, either through careful use of the execute method
> on the mojo's or just being able to test the supporting methods like special
> filename manipulation, downloading a wsdl from a website, perhaps even
> generating some code. Basically, anything and everything that you can
> massage on the plugin that doesn't stray into complex objects like
> MavenProject, or ArtifactManagers or anything.
>
> 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 were kind of a mind that stubbing and
> mocking up these project objects and whatnot don't represent reality very
> well and perhaps the best solution would be to follow the route of the
> integration plugin where we can craft little projects in the plugin
> directory that represent real life usages of the plugin, then we verify that
> the right thing was done. This verification could take the form of
> validating the resulting directory structure matched an outcome, certain
> files matched an outcome, or the state of objects in the project matched the
> template.
>
> This all seems pretty obvious, but I wanted to at least start a conversation
> about how we ought to test these plugins. I like this clear delineation in
> that it draws a line in the sand as to what can get tested where between
> src/test/java and src/it/*. It also encourages a clean plugin design as the
> unit testing should make it simple for you to easily test the checking of
> variable existence and states and helper methods. Although, I know vincent
> has had some success with mocking up some of the more complex objects so I
> would be interested in his thoughts on the matter...and bretts as well on if
> I am barking up the wrong tree...
>
> so, thoughts?
>
> jesse
>
> --
> jesse mcconnell
> jesseDOTmcconnellATgmailDOTcom
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-2084) Jar plugin does not respect the authority of the element
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 have a simple jar plugin with the following build element org.apache.maven.plugins maven-compiler-plugin 1.5 1.5 foo.jas However, when building I get a final artifact with the name 'foo.jas.jar' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: plugin testing
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 were kind of a mind that stubbing and mocking up these project objects and whatnot don't represent reality very well and perhaps the best solution would be to follow the route of the integration plugin where we can craft little projects in the plugin directory that represent real life usages of the plugin, then we verify that the right thing was done. This verification could take the form of validating the resulting directory structure matched an outcome, certain files matched an outcome, or the state of objects in the project matched the template. I agree about not mocking anything for integration testing. How is that different from what the it and verifier plugin currently do? It's possible that we already have everything we need for executing and verifying integration tests, though I'd really like to see options for setup and tear-down of the environment as well. However, more to the point, I think we need to provide some sort of archetype or something to bring all of these myriad solution-parts together into something people can easily hook into for testing...with minimal fuss. Thanks for starting this discussion, Jesse. It's really important that we get this sorted out soon, so we can bring plugin development out of the stone age! :-) My 2c. -john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] adding pre/post phases for all major lifecycle phases
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's also bound by the packaging, this won't be possible unless we have a way for specifying the default mojos in the ordering too... Or, were you addressing the comment about a shorthand? If so, I agree that's not absolutely required, since people customizing to this level are probably going to know what the default lifecycle mappings are. -j Jesse McConnell wrote: 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 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 by the packaging. You shouldn't need to deal with the ordering of the default mojos in the 'jar' packaging, for example. -j Eric Redmond wrote: 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 becomes a question of what is the easiest way to represent these steps into an easily understandable sequence? (Or even a sequence at all, because that particular case sounds more like a graph). To me, I'd rather see the steps labeled into descreet units (ala consolidated goal or inter-phase-ordering) to give a clearer big-picture view. For example: generate-resources: 1. generate ANLTR 2. compile grammer 3. generate java code from it compile: 1. compile java code Or in graph form? generate-resources: generate ANLTR compile: compile grammer generate-resources: generate java code from it compile: compile java code Rather than: generate-resources (pre): generate ANLTR generate-resources: compile grammer generate-resources (post): generate java code from it compile: compile java code On 2/17/06, Jesse McConnell <[EMAIL PROTECTED]> wrote: 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. Adding in more phases, or ordering within a phase just makes the pom get more and more complex which (in my mind) defeats one of the goals of maven... sure it is technically possible to glom as much as you can into a pom, but understandability goes down quickly and we are left with a process that isn't a scads better then the others, like maven is right now IMO. :) I understand people are really used to combining as much as they can into one building entity, but it that going to be our best practice? jesse On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: 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 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, I have a list of goals that need met. With the pre/post thing, it is effectively saying "You can have at most three goals met per phase". Another option is to have some sort of consolidation goal that would then be called on a phase, whose definition is an ordered list of goals, I kind of like this better, as it will keep the syntax cleaner, and honestly, how often do you need to cram multiple goals into a phase? One or two at most? Eric On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: 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 that model. Both should fit in generate-sources, but there's a definite order here. Maybe the solution is to split the project in two, one -model, and another -parser or something. Still, it seems like we're putting a band-aid on the problem by adding more phases. Would it be better to add control over or
Re: plugin testing
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 not long ago) - it tests can be done with something like the it-core does for maven. We need to agree where should they be in the directory structure. As we're not providing the support in core people is wasting effort in each plugin to do this, eg in the aspectj there's a unit test that calls the MavenEmbedder to run the mojo in an it test, and also a mock of Artifact. On 2/17/06, Jesse McConnell <[EMAIL PROTECTED]> wrote: > 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'll jump right to the chase. > > We need someway to be able to gather code coverage metrics from plugin > testing so we have at least a modicum of belief that changes didn't break > anything, and since plugins can be so amazingly complex in many cases and > just downright trivial in others there can't be a one size fits all > solutionso > > I propose that we break the problem down into two neat little parts. First > would be actual plugin unit testing were we have a simple way to > instantiating the plugin and any of the pretty normal variables that get > injected, collections, strings, bool, etc. then we have basic junit type > testing on these objects, either through careful use of the execute method > on the mojo's or just being able to test the supporting methods like special > filename manipulation, downloading a wsdl from a website, perhaps even > generating some code. Basically, anything and everything that you can > massage on the plugin that doesn't stray into complex objects like > MavenProject, or ArtifactManagers or anything. > > 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 were kind of a mind that stubbing and > mocking up these project objects and whatnot don't represent reality very > well and perhaps the best solution would be to follow the route of the > integration plugin where we can craft little projects in the plugin > directory that represent real life usages of the plugin, then we verify that > the right thing was done. This verification could take the form of > validating the resulting directory structure matched an outcome, certain > files matched an outcome, or the state of objects in the project matched the > template. > > This all seems pretty obvious, but I wanted to at least start a conversation > about how we ought to test these plugins. I like this clear delineation in > that it draws a line in the sand as to what can get tested where between > src/test/java and src/it/*. It also encourages a clean plugin design as the > unit testing should make it simple for you to easily test the checking of > variable existence and states and helper methods. Although, I know vincent > has had some success with mocking up some of the more complex objects so I > would be interested in his thoughts on the matter...and bretts as well on if > I am barking up the wrong tree... > > so, thoughts? > > jesse > > -- > jesse mcconnell > jesseDOTmcconnellATgmailDOTcom > > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: plugin testing
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 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'll jump right to the chase. Hey thanks for taking this up! :-) > We need someway to be able to gather code coverage metrics from plugin > testing so we have at least a modicum of belief that changes didn't break > anything, and since plugins can be so amazingly complex in many cases and > just downright trivial in others there can't be a one size fits all > solutionso > > I propose that we break the problem down into two neat little parts. > First > would be actual plugin unit testing were we have a simple way to > instantiating the plugin For unit testing, the way I do is simple: new MyPlugin()! > and any of the pretty normal variables that get > injected, collections, strings, bool, etc. I add setters to my plugins for this. BTW I have an example of unit testing a plugin here: http://tinyurl.com/a2cmh [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 were kind of a mind that stubbing and > mocking up these project objects and whatnot don't represent reality very > well and perhaps the best solution would be to follow the route of the > integration plugin where we can craft little projects in the plugin > directory that represent real life usages of the plugin, then we verify > that > the right thing was done. This verification could take the form of > validating the resulting directory structure matched an outcome, certain > files matched an outcome, or the state of objects in the project matched > the > template. I agree about not mocking anything for integration testing. How is that different from what the it and verifier plugin currently do? [snip] Thanks! -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
plugin testing
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'll jump right to the chase. We need someway to be able to gather code coverage metrics from plugin testing so we have at least a modicum of belief that changes didn't break anything, and since plugins can be so amazingly complex in many cases and just downright trivial in others there can't be a one size fits all solutionso I propose that we break the problem down into two neat little parts. First would be actual plugin unit testing were we have a simple way to instantiating the plugin and any of the pretty normal variables that get injected, collections, strings, bool, etc. then we have basic junit type testing on these objects, either through careful use of the execute method on the mojo's or just being able to test the supporting methods like special filename manipulation, downloading a wsdl from a website, perhaps even generating some code. Basically, anything and everything that you can massage on the plugin that doesn't stray into complex objects like MavenProject, or ArtifactManagers or anything. 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 were kind of a mind that stubbing and mocking up these project objects and whatnot don't represent reality very well and perhaps the best solution would be to follow the route of the integration plugin where we can craft little projects in the plugin directory that represent real life usages of the plugin, then we verify that the right thing was done. This verification could take the form of validating the resulting directory structure matched an outcome, certain files matched an outcome, or the state of objects in the project matched the template. This all seems pretty obvious, but I wanted to at least start a conversation about how we ought to test these plugins. I like this clear delineation in that it draws a line in the sand as to what can get tested where between src/test/java and src/it/*. It also encourages a clean plugin design as the unit testing should make it simple for you to easily test the checking of variable existence and states and helper methods. Although, I know vincent has had some success with mocking up some of the more complex objects so I would be interested in his thoughts on the matter...and bretts as well on if I am barking up the wrong tree... so, thoughts? jesse -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom
[jira] Updated: (MNG-2083) Path to missing dependency is not shown nor url to download
[ 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 http://java.sun.com/products/javabeans/glasgow/jaf.html and install it using the command: mvn install:install-file -DgroupId=javax.activation -DartifactId=activation -Dversion=1.0.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) test:test:jar:1.0-SNAPSHOT 2) javax.activation:activation:jar:1.0.2 javax.activation:activation:jar:1.0.2 was: Seems a regression it's only shown with -X [DEBUG] Unable to download the artifact from any repository Path to dependency: 1) org.apache.activemq:activemq-jaas:jar:4.0-SNAPSHOT 2) directory-asn1:asn1-ber:jar:0.3.2 3) commons-test:commons-test:jar:0.1 Testcase included: yes Fix Version: 2.0.3 Attachment: pom.xml Summary: Path to missing dependency is not shown nor url to download (was: Path to missing dependency is not shown) > Path to missing dependency is not shown nor url to download > > > 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: Blocker > Fix For: 2.0.3 > Attachments: pom.xml > > > Seems a regression > it's only shown with -X > [DEBUG] Unable to download the artifact from any repository > Try downloading the file manually from > http://java.sun.com/products/javabeans/glasgow/jaf.html > and install it using the command: > mvn install:install-file -DgroupId=javax.activation -DartifactId=activation > -Dversion=1.0.2 -Dpackaging=jar -Dfile=/path/to/file > Path to dependency: > 1) test:test:jar:1.0-SNAPSHOT > 2) javax.activation:activation:jar:1.0.2 > javax.activation:activation:jar:1.0.2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-2083) Path to missing dependency is not shown
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: Blocker Seems a regression it's only shown with -X [DEBUG] Unable to download the artifact from any repository Path to dependency: 1) org.apache.activemq:activemq-jaas:jar:4.0-SNAPSHOT 2) directory-asn1:asn1-ber:jar:0.3.2 3) commons-test:commons-test:jar:0.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-2082) assembly:assembly doesn't recognize pre-defined assembly types
[ 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 > -- > > Key: MNG-2082 > URL: http://jira.codehaus.org/browse/MNG-2082 > Project: Maven 2 > Type: Bug > Components: Artifacts > Versions: 2.0.2 > Reporter: Howard M. Lewis Ship > Attachments: pom.xml > > > I'm trying to build a source bundle for uploading to my download site. The > following should work, if I'm folloiwng the documentation property, but > doesn't. > bash-3.00$ mvn assembly:assembly -Dmaven.assembly.descriptorId=src > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'assembly'. > [INFO] > > [INFO] Building Tapestry prop binding extension > [INFO]task-segment: [assembly:assembly] (aggregator-style) > [INFO] > > [INFO] Preparing assembly:assembly > [INFO] > > [INFO] Building Tapestry prop binding extension > [INFO] > > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:compile] > [INFO] Nothing to compile - all classes are up to date > [INFO] [resources:testResources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:testCompile] > [INFO] Nothing to compile - all classes are up to date > [INFO] [surefire:test] > [INFO] Setting reports dir: c:\workspace\tapestry-prop\target/surefire-reports > --- > T E S T S > --- > [surefire] Running org.apache.tapestry.prop.PropertyAccessorBindingFactoryTest > [surefire] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.094 sec > [surefire] Running org.apache.tapestry.prop.PropertyAccessorClassFactoryTest > [surefire] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.187 sec > [surefire] Running org.apache.tapestry.prop.PropertyAccessorSourceTest > [surefire] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.031 sec > Results : > [surefire] Tests run: 10, Failures: 0, Errors: 0 > [INFO] [jar:jar] > [INFO] Building jar: c:\workspace\tapestry-prop\target\tapestry-prop-0.1.1.jar > [INFO] [assembly:assembly] > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] No assembly descriptors found. > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 2 seconds > [INFO] Finished at: Fri Feb 17 08:08:55 PST 2006 > [INFO] Final Memory: 5M/10M > [INFO] > > bash-3.00$ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] adding pre/post phases for all major lifecycle phases
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 server side and also use the generated wsdl to generate java files. There's now 2 ways : the wsdl file is added in the jar of the api or the wsdl file is attached as a classifier to the api.jar To fix the problem : - allow the adding of resource post compilation (to have the wsdl in the jar) - move the generate-resources phase after compilation (as it is not needed to compile, the only constraint is to have the resource well placed before testing) - create a new packaging (say axis-api) for axistools which binds the generate-resource phase between compilation and test The third one has my preference. Maybe a way to get rid of the phases proliferation is to make proliferate the packagings. Therefore, the complexity of the phases are hidden in the plugins-packaging and not shown in the pom which add the confusion to the users. Is that makes sense ? Raphaël John Casey a écrit : 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 bindings can come from: 1. packaging lifecycle mapping 2. parent POM 3. profiles 4. POM 5. (am I missing something?) So, any syntax would have to support this layering in a way that wouldn't be overly confusing. FWIW, I think I have a band-aid on my client's project that will work for the time being. I'd much rather see this stuff fixed correctly soon, rather than have 10,000 lifecycle phases to support for backward compatibility later on... -john Jesse McConnell wrote: +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 next layer of complexity with some type of ordering maybe.. Providing a mechansim of strict execution ordering inside of a lifecycle phase could address this.. Custom lifecycle phases and goals declared in the pom that can be bound by plugins inside of the pom? (icky) Otherwise it is just too easy to keep adding on layers of pre and post processing :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] adding pre/post phases for all major lifecycle phases
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 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 by the packaging. You shouldn't need to deal with the > ordering of the default mojos in the 'jar' packaging, for example. > > -j > > Eric Redmond wrote: > > 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 > becomes a > > question of what is the easiest way to represent these steps into an > easily > > understandable sequence? (Or even a sequence at all, because that > particular > > case sounds more like a graph). > > > > To me, I'd rather see the steps labeled into descreet units (ala > > consolidated goal or inter-phase-ordering) to give a clearer big-picture > > view. For example: > > > > generate-resources: > > 1. generate ANLTR > > 2. compile grammer > > 3. generate java code from it > > compile: > > 1. compile java code > > > > Or in graph form? > > generate-resources: > > generate ANLTR > > compile: > > compile grammer > > generate-resources: > > generate java code from it > > compile: > > compile java code > > > > Rather than: > > generate-resources (pre): > > generate ANLTR > > generate-resources: > > compile grammer > > generate-resources (post): > > generate java code from it > > compile: > > compile java code > > > > > > > > On 2/17/06, Jesse McConnell <[EMAIL PROTECTED]> wrote: > >> 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. Adding in more > phases, > >> or ordering within a phase just makes the pom get more and more complex > >> which (in my mind) defeats one of the goals of maven... > >> > >> sure it is technically possible to glom as much as you can into a pom, > but > >> understandability goes down quickly and we are left with a process that > >> isn't a scads better then the others, like maven is right now IMO. :) > >> > >> I understand people are really used to combining as much as they can > into > >> one building entity, but it that going to be our best practice? > >> > >> jesse > >> > >> > >> On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: > >>> 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 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, > >>> I > have a list of goals that need met. With the pre/post thing, it is > effectively saying "You can have at most three goals met per phase". > >>> Another > option is to have some sort of consolidation goal that would then be > >>> called > on a phase, whose definition is an ordered list of goals, I kind of > >> like > this better, as it will keep the syntax cleaner, and honestly, how > >> often > >>> do > you need to cram multiple goals into a phase? One or two at most? > > Eric > > On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: > > 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 that model. > > > > Both should fit in generate-sources, but there's a definite order > >> here. > > Maybe the solution is to split the project in two, one -model, and > > another -parser or something. Still, it seems like we're putting a > > band-aid on the problem by adding more phases. Would it be better to > >>> add > > control over ordering within a phase? How would that even look in > > syntax? > > > > What do you all think?
Re: [proposal] adding pre/post phases for all major lifecycle phases
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 by the packaging. You shouldn't need to deal with the ordering of the default mojos in the 'jar' packaging, for example. -j Eric Redmond wrote: 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 becomes a question of what is the easiest way to represent these steps into an easily understandable sequence? (Or even a sequence at all, because that particular case sounds more like a graph). To me, I'd rather see the steps labeled into descreet units (ala consolidated goal or inter-phase-ordering) to give a clearer big-picture view. For example: generate-resources: 1. generate ANLTR 2. compile grammer 3. generate java code from it compile: 1. compile java code Or in graph form? generate-resources: generate ANLTR compile: compile grammer generate-resources: generate java code from it compile: compile java code Rather than: generate-resources (pre): generate ANLTR generate-resources: compile grammer generate-resources (post): generate java code from it compile: compile java code On 2/17/06, Jesse McConnell <[EMAIL PROTECTED]> wrote: 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. Adding in more phases, or ordering within a phase just makes the pom get more and more complex which (in my mind) defeats one of the goals of maven... sure it is technically possible to glom as much as you can into a pom, but understandability goes down quickly and we are left with a process that isn't a scads better then the others, like maven is right now IMO. :) I understand people are really used to combining as much as they can into one building entity, but it that going to be our best practice? jesse On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: 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 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, I have a list of goals that need met. With the pre/post thing, it is effectively saying "You can have at most three goals met per phase". Another option is to have some sort of consolidation goal that would then be called on a phase, whose definition is an ordered list of goals, I kind of like this better, as it will keep the syntax cleaner, and honestly, how often do you need to cram multiple goals into a phase? One or two at most? Eric On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: 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 that model. Both should fit in generate-sources, but there's a definite order here. Maybe the solution is to split the project in two, one -model, and another -parser or something. Still, it seems like we're putting a band-aid on the problem by adding more phases. Would it be better to add control over ordering within a phase? How would that even look in syntax? What do you all think? -j 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. 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 approach anymore. I'll give you an example: Say I have two mojos bound to the package phase, for lack of a better place. The first takes the tested code, and assembles the directory structure for the archive. The second creates the archive. If I want to replace the first step, I can add a 'skip' flag to it, but I *cannot* bind a new mojo in its place; any new binding will be added after the second step. Obviously, it makes no sense to prepare an archive directory structure *after* the archive is created. This is not the
Re: [proposal] adding pre/post phases for all major lifecycle phases
+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 clear as way as > possible... > > > > > > compile > > compile-one > compile-two > > . > . > . > > then in the plugin bind the phase to compile-one > > jesse > > On 2/17/06, Jesse McConnell <[EMAIL PROTECTED]> wrote: > > > > > > 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. Adding in > > more phases, or ordering within a phase just makes the pom get more and > more > > complex which (in my mind) defeats one of the goals of maven... > > > > sure it is technically possible to glom as much as you can into a pom, > but > > understandability goes down quickly and we are left with a process that > > isn't a scads better then the others, like maven is right now IMO. :) > > > > I understand people are really used to combining as much as they can > into > > one building entity, but it that going to be our best practice? > > > > jesse > > > > > > On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: > > > > > > 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 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, I > > > > have a list of goals that need met. With the pre/post thing, it is > > > > effectively saying "You can have at most three goals met per phase". > > > Another > > > > option is to have some sort of consolidation goal that would then be > > > called > > > > on a phase, whose definition is an ordered list of goals, I kind of > > > like > > > > this better, as it will keep the syntax cleaner, and honestly, how > > > often do > > > > you need to cram multiple goals into a phase? One or two at most? > > > > > > > > Eric > > > > > > > > On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: > > > >> 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 that model. > > > >> > > > >> Both should fit in generate-sources, but there's a definite order > > > here. > > > >> Maybe the solution is to split the project in two, one -model, and > > > >> another -parser or something. Still, it seems like we're putting a > > > >> band-aid on the problem by adding more phases. Would it be better > to > > > add > > > >> control over ordering within a phase? How would that even look in > > > >> syntax? > > > >> > > > >> What do you all think? > > > >> > > > >> -j > > > >> > > > >> 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. 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 > > > >>> approach anymore. I'll give you an example: > > > >>> > > > >>> Say I have two mojos bound to the package phase, for lack of a > > > better > > > >>> place. The first takes the tested code, and assembles the > directory > > > >>> structure for the archive. The second creates the archive. If I > want > > > to > > > >>> replace the first step, I can add a 'skip' flag to it, but I > > > *cannot* > > > >>> bind a new mojo in its place; any new binding will be added after > > > the > > > >>> second step. Obviously, it makes no sense to prepare an archive > > > >>> directory structure *after* the archive is created. > > > >>> > > > >>> This is not the first time we've discussed this sort of thing. We > > > have > > > >>> pre/post phases for setup and tear-down of integration tests, and > > > should > > > >>> probably have something similar for unit tests...not to mention, > > > >>> install, deploy... > > > >>> > > > >>> It doesn't seem like a good idea to continue addressing this > p
Re: [proposal] adding pre/post phases for all major lifecycle phases
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 the developers could leverage things like Maven and CVS. However, the project structure still had to interact with that legacy build system for legal reasons. If it weren't for Maven's flexibility in that matter, we never could have used it. IMO it is enough simply to make it easier to create new projects in a correct way. New projects will tend to do whats easiest at the time. Thats almost a good case for making it complicated and ugly to add multiple steps into a phase via an extension, rather than modifying the phases at its core. But it still needs to be possible for those sad souls who cannot change their project structures at all. Eric On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: > > 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 > porject, but in reality this *really* should be split into multiple > projects: > > project-model > project-parser > project-* > > in the same way Maven itself is split up. > > HOWEVER, I think we also need to understand that there are going to be > legacy use cases out there, where people don't have control over the > project structure. If someone can't split up their project like above, > do we want to turn them away at the door? In the past, I think Maven has > tended to focus a little too tightly on new project development. IMO, we > need to be more careful to accommodate these legacy cases in the future. > > To be clear, I don't want to encourage bad project design. I'm very much > against shoving everything into one build just because it's possible. > But, it should be possible, in order to accommodate those users who are > dealing with bad project design that is outside of their control. > > Cheers, > > John > > Jesse McConnell wrote: > > 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. Adding in more > phases, > > or ordering within a phase just makes the pom get more and more complex > > which (in my mind) defeats one of the goals of maven... > > > > sure it is technically possible to glom as much as you can into a pom, > but > > understandability goes down quickly and we are left with a process that > > isn't a scads better then the others, like maven is right now IMO. :) > > > > I understand people are really used to combining as much as they can > into > > one building entity, but it that going to be our best practice? > > > > jesse > > > > > > On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: > >> 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 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, > >> I > >>> have a list of goals that need met. With the pre/post thing, it is > >>> effectively saying "You can have at most three goals met per phase". > >> Another > >>> option is to have some sort of consolidation goal that would then be > >> called > >>> on a phase, whose definition is an ordered list of goals, I kind of > like > >>> this better, as it will keep the syntax cleaner, and honestly, how > often > >> do > >>> you need to cram multiple goals into a phase? One or two at most? > >>> > >>> Eric > >>> > >>> On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: > 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 that model. > > Both should fit in generate-sources, but there's a definite order > here. > Maybe the solution is to split the project in two, one -model, and > another -parser or something. Still, it seems like we're putting a > band-aid on the problem by adding more phases. Would it be better to > >> add
Re: [proposal] adding pre/post phases for all major lifecycle phases
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 becomes a question of what is the easiest way to represent these steps into an easily understandable sequence? (Or even a sequence at all, because that particular case sounds more like a graph). To me, I'd rather see the steps labeled into descreet units (ala consolidated goal or inter-phase-ordering) to give a clearer big-picture view. For example: generate-resources: 1. generate ANLTR 2. compile grammer 3. generate java code from it compile: 1. compile java code Or in graph form? generate-resources: generate ANLTR compile: compile grammer generate-resources: generate java code from it compile: compile java code Rather than: generate-resources (pre): generate ANLTR generate-resources: compile grammer generate-resources (post): generate java code from it compile: compile java code On 2/17/06, Jesse McConnell <[EMAIL PROTECTED]> wrote: > > 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. Adding in more phases, > or ordering within a phase just makes the pom get more and more complex > which (in my mind) defeats one of the goals of maven... > > sure it is technically possible to glom as much as you can into a pom, but > understandability goes down quickly and we are left with a process that > isn't a scads better then the others, like maven is right now IMO. :) > > I understand people are really used to combining as much as they can into > one building entity, but it that going to be our best practice? > > jesse > > > On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: > > > > 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 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, > > I > > > have a list of goals that need met. With the pre/post thing, it is > > > effectively saying "You can have at most three goals met per phase". > > Another > > > option is to have some sort of consolidation goal that would then be > > called > > > on a phase, whose definition is an ordered list of goals, I kind of > like > > > this better, as it will keep the syntax cleaner, and honestly, how > often > > do > > > you need to cram multiple goals into a phase? One or two at most? > > > > > > Eric > > > > > > On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: > > >> 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 that model. > > >> > > >> Both should fit in generate-sources, but there's a definite order > here. > > >> Maybe the solution is to split the project in two, one -model, and > > >> another -parser or something. Still, it seems like we're putting a > > >> band-aid on the problem by adding more phases. Would it be better to > > add > > >> control over ordering within a phase? How would that even look in > > >> syntax? > > >> > > >> What do you all think? > > >> > > >> -j > > >> > > >> 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. 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 > > >>> approach anymore. I'll give you an example: > > >>> > > >>> Say I have two mojos bound to the package phase, for lack of a > better > > >>> place. The first takes the tested code, and assembles the directory > > >>> structure for the archive. The second creates the archive. If I want > > to > > >>> replace the first step, I can add a 'skip' flag to it, but I > *cannot* > > >>> bind a new mojo in its place; any new binding will be added after > the > > >>> second step. Obviously, it makes no sense to prepare an archive > > >>> directory structure *after* the archive is created. > > >>> > > >>> This is not the first time
Re: [proposal] adding pre/post phases for all major lifecycle phases
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 are specified, we would still have to merge in the phases of the overall lifecycle where there are no collisions. --john John Casey wrote: +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 to have some generic placeholders like or something, so we can say, "Add these in this order BEFORE we add the packaging mappings...even though I don't know what those are." -j Jesse McConnell 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 clear as way as possible... compile compile-one compile-two . . . then in the plugin bind the phase to compile-one jesse On 2/17/06, Jesse McConnell <[EMAIL PROTECTED]> wrote: 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. Adding in more phases, or ordering within a phase just makes the pom get more and more complex which (in my mind) defeats one of the goals of maven... sure it is technically possible to glom as much as you can into a pom, but understandability goes down quickly and we are left with a process that isn't a scads better then the others, like maven is right now IMO. :) I understand people are really used to combining as much as they can into one building entity, but it that going to be our best practice? jesse On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: 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 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, I have a list of goals that need met. With the pre/post thing, it is effectively saying "You can have at most three goals met per phase". Another option is to have some sort of consolidation goal that would then be called on a phase, whose definition is an ordered list of goals, I kind of like this better, as it will keep the syntax cleaner, and honestly, how often do you need to cram multiple goals into a phase? One or two at most? Eric On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: 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 that model. Both should fit in generate-sources, but there's a definite order here. Maybe the solution is to split the project in two, one -model, and another -parser or something. Still, it seems like we're putting a band-aid on the problem by adding more phases. Would it be better to add control over ordering within a phase? How would that even look in syntax? What do you all think? -j 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. 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 approach anymore. I'll give you an example: Say I have two mojos bound to the package phase, for lack of a better place. The first takes the tested code, and assembles the directory structure for the archive. The second creates the archive. If I want to replace the first step, I can add a 'skip' flag to it, but I *cannot* bind a new mojo in its place; any new binding will be added after the second step. Obviously, it makes no sense to prepare an archive directory structure *after* the archive is created. This is not the first time we've discussed this sort of thing. We have pre/post phases for setup and tear-down of integration tests, and should probably have something similar for uni
Re: [proposal] adding pre/post phases for all major lifecycle phases
+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 to have some generic placeholders like or something, so we can say, "Add these in this order BEFORE we add the packaging mappings...even though I don't know what those are." -j Jesse McConnell 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 clear as way as possible... compile compile-one compile-two . . . then in the plugin bind the phase to compile-one jesse On 2/17/06, Jesse McConnell <[EMAIL PROTECTED]> wrote: 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. Adding in more phases, or ordering within a phase just makes the pom get more and more complex which (in my mind) defeats one of the goals of maven... sure it is technically possible to glom as much as you can into a pom, but understandability goes down quickly and we are left with a process that isn't a scads better then the others, like maven is right now IMO. :) I understand people are really used to combining as much as they can into one building entity, but it that going to be our best practice? jesse On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: 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 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, I have a list of goals that need met. With the pre/post thing, it is effectively saying "You can have at most three goals met per phase". Another option is to have some sort of consolidation goal that would then be called on a phase, whose definition is an ordered list of goals, I kind of like this better, as it will keep the syntax cleaner, and honestly, how often do you need to cram multiple goals into a phase? One or two at most? Eric On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: 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 that model. Both should fit in generate-sources, but there's a definite order here. Maybe the solution is to split the project in two, one -model, and another -parser or something. Still, it seems like we're putting a band-aid on the problem by adding more phases. Would it be better to add control over ordering within a phase? How would that even look in syntax? What do you all think? -j 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. 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 approach anymore. I'll give you an example: Say I have two mojos bound to the package phase, for lack of a better place. The first takes the tested code, and assembles the directory structure for the archive. The second creates the archive. If I want to replace the first step, I can add a 'skip' flag to it, but I *cannot* bind a new mojo in its place; any new binding will be added after the second step. Obviously, it makes no sense to prepare an archive directory structure *after* the archive is created. This is not the first time we've discussed this sort of thing. We have pre/post phases for setup and tear-down of integration tests, and should probably have something similar for unit tests...not to mention, install, deploy... It doesn't seem like a good idea to continue addressing this problem an issue at a time in successive Maven releases. Why not make a reasonable concession to these use cases, and add pre/post phases to each major lifecycle phase (those which are themselves pre/post phases are not what I consider major). I'd like to get this into 2.0.3, since it affects some work I'm doing for a client. What do
[jira] Created: (CONTINUUM-594) Update Maven dependencies to 2.0.3
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 Fix For: 1.0.3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-534) Release Continunum 1.0.3
[ 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) > Release Continunum 1.0.3 > > > Key: CONTINUUM-534 > URL: http://jira.codehaus.org/browse/CONTINUUM-534 > Project: Continuum > Type: Task > Reporter: Trygve Laugstol > Assignee: Emmanuel Venisse > Fix For: 1.0.3 > > > This is a "collection issue" which will depend on any issues from other > projects that should be solved before the release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[maven2 build branches/maven-2.0.x - SUCCESS - update] Fri Feb 17 16:45:00 GMT 2006
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-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] adding pre/post phases for all major lifecycle phases
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 porject, but in reality this *really* should be split into multiple projects: project-model project-parser project-* in the same way Maven itself is split up. HOWEVER, I think we also need to understand that there are going to be legacy use cases out there, where people don't have control over the project structure. If someone can't split up their project like above, do we want to turn them away at the door? In the past, I think Maven has tended to focus a little too tightly on new project development. IMO, we need to be more careful to accommodate these legacy cases in the future. To be clear, I don't want to encourage bad project design. I'm very much against shoving everything into one build just because it's possible. But, it should be possible, in order to accommodate those users who are dealing with bad project design that is outside of their control. Cheers, John Jesse McConnell wrote: 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. Adding in more phases, or ordering within a phase just makes the pom get more and more complex which (in my mind) defeats one of the goals of maven... sure it is technically possible to glom as much as you can into a pom, but understandability goes down quickly and we are left with a process that isn't a scads better then the others, like maven is right now IMO. :) I understand people are really used to combining as much as they can into one building entity, but it that going to be our best practice? jesse On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: 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 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, I have a list of goals that need met. With the pre/post thing, it is effectively saying "You can have at most three goals met per phase". Another option is to have some sort of consolidation goal that would then be called on a phase, whose definition is an ordered list of goals, I kind of like this better, as it will keep the syntax cleaner, and honestly, how often do you need to cram multiple goals into a phase? One or two at most? Eric On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: 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 that model. Both should fit in generate-sources, but there's a definite order here. Maybe the solution is to split the project in two, one -model, and another -parser or something. Still, it seems like we're putting a band-aid on the problem by adding more phases. Would it be better to add control over ordering within a phase? How would that even look in syntax? What do you all think? -j 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. 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 approach anymore. I'll give you an example: Say I have two mojos bound to the package phase, for lack of a better place. The first takes the tested code, and assembles the directory structure for the archive. The second creates the archive. If I want to replace the first step, I can add a 'skip' flag to it, but I *cannot* bind a new mojo in its place; any new binding will be added after the second step. Obviously, it makes no sense to prepare an archive directory structure *after* the archive is created. This is not the first time we've discussed this sort of thing. We have pre/post phases for setup and tear-down of integration tests, and should probably have something similar for unit tests...not to mention, install, deploy... It doesn't seem like a good idea to continue addressing this problem an issue at a time in successive Maven releases. Why not make a reasonable concession to these use cases, and add pre/post
Re: [proposal] adding pre/post phases for all major lifecycle phases
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/06, John Casey <[EMAIL PROTECTED]> wrote: > > 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 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, > I > > have a list of goals that need met. With the pre/post thing, it is > > effectively saying "You can have at most three goals met per phase". > Another > > option is to have some sort of consolidation goal that would then be > called > > on a phase, whose definition is an ordered list of goals, I kind of like > > this better, as it will keep the syntax cleaner, and honestly, how often > do > > you need to cram multiple goals into a phase? One or two at most? > > > > Eric > > > > On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: > >> 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 that model. > >> > >> Both should fit in generate-sources, but there's a definite order here. > >> Maybe the solution is to split the project in two, one -model, and > >> another -parser or something. Still, it seems like we're putting a > >> band-aid on the problem by adding more phases. Would it be better to > add > >> control over ordering within a phase? How would that even look in > >> syntax? > >> > >> What do you all think? > >> > >> -j > >> > >> 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. 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 > >>> approach anymore. I'll give you an example: > >>> > >>> Say I have two mojos bound to the package phase, for lack of a better > >>> place. The first takes the tested code, and assembles the directory > >>> structure for the archive. The second creates the archive. If I want > to > >>> replace the first step, I can add a 'skip' flag to it, but I *cannot* > >>> bind a new mojo in its place; any new binding will be added after the > >>> second step. Obviously, it makes no sense to prepare an archive > >>> directory structure *after* the archive is created. > >>> > >>> This is not the first time we've discussed this sort of thing. We have > >>> pre/post phases for setup and tear-down of integration tests, and > should > >>> probably have something similar for unit tests...not to mention, > >>> install, deploy... > >>> > >>> It doesn't seem like a good idea to continue addressing this problem > an > >>> issue at a time in successive Maven releases. Why not make a > reasonable > >>> concession to these use cases, and add pre/post phases to each major > >>> lifecycle phase (those which are themselves pre/post phases are not > what > >>> I consider major). > >>> > >>> I'd like to get this into 2.0.3, since it affects some work I'm doing > >>> for a client. > >>> > >>> What do you all think? > >>> > >>> -john > >>> > >>> - > >>> 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: [proposal] adding pre/post phases for all major lifecycle phases
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 compile-one compile-two . . . then in the plugin bind the phase to compile-one jesse On 2/17/06, Jesse McConnell <[EMAIL PROTECTED]> wrote: > > > 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. Adding in > more phases, or ordering within a phase just makes the pom get more and more > complex which (in my mind) defeats one of the goals of maven... > > sure it is technically possible to glom as much as you can into a pom, but > understandability goes down quickly and we are left with a process that > isn't a scads better then the others, like maven is right now IMO. :) > > I understand people are really used to combining as much as they can into > one building entity, but it that going to be our best practice? > > jesse > > > On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: > > > > 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 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, I > > > have a list of goals that need met. With the pre/post thing, it is > > > effectively saying "You can have at most three goals met per phase". > > Another > > > option is to have some sort of consolidation goal that would then be > > called > > > on a phase, whose definition is an ordered list of goals, I kind of > > like > > > this better, as it will keep the syntax cleaner, and honestly, how > > often do > > > you need to cram multiple goals into a phase? One or two at most? > > > > > > Eric > > > > > > On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: > > >> 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 that model. > > >> > > >> Both should fit in generate-sources, but there's a definite order > > here. > > >> Maybe the solution is to split the project in two, one -model, and > > >> another -parser or something. Still, it seems like we're putting a > > >> band-aid on the problem by adding more phases. Would it be better to > > add > > >> control over ordering within a phase? How would that even look in > > >> syntax? > > >> > > >> What do you all think? > > >> > > >> -j > > >> > > >> 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. 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 > > >>> approach anymore. I'll give you an example: > > >>> > > >>> Say I have two mojos bound to the package phase, for lack of a > > better > > >>> place. The first takes the tested code, and assembles the directory > > >>> structure for the archive. The second creates the archive. If I want > > to > > >>> replace the first step, I can add a 'skip' flag to it, but I > > *cannot* > > >>> bind a new mojo in its place; any new binding will be added after > > the > > >>> second step. Obviously, it makes no sense to prepare an archive > > >>> directory structure *after* the archive is created. > > >>> > > >>> This is not the first time we've discussed this sort of thing. We > > have > > >>> pre/post phases for setup and tear-down of integration tests, and > > should > > >>> probably have something similar for unit tests...not to mention, > > >>> install, deploy... > > >>> > > >>> It doesn't seem like a good idea to continue addressing this problem > > an > > >>> issue at a time in successive Maven releases. Why not make a > > reasonable > > >>> concession to these use cases, and add pre/post phases to each major > > > > >>> lifecycle phase (those which are themselves pre/post phases are not > > what > > >>> I consider major). > > >>> > > >>> I'd like to get this into 2.0.3, since it affects
Re: [proposal] adding pre/post phases for all major lifecycle phases
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. Adding in more phases, or ordering within a phase just makes the pom get more and more complex which (in my mind) defeats one of the goals of maven... sure it is technically possible to glom as much as you can into a pom, but understandability goes down quickly and we are left with a process that isn't a scads better then the others, like maven is right now IMO. :) I understand people are really used to combining as much as they can into one building entity, but it that going to be our best practice? jesse On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: > > 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 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, > I > > have a list of goals that need met. With the pre/post thing, it is > > effectively saying "You can have at most three goals met per phase". > Another > > option is to have some sort of consolidation goal that would then be > called > > on a phase, whose definition is an ordered list of goals, I kind of like > > this better, as it will keep the syntax cleaner, and honestly, how often > do > > you need to cram multiple goals into a phase? One or two at most? > > > > Eric > > > > On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: > >> 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 that model. > >> > >> Both should fit in generate-sources, but there's a definite order here. > >> Maybe the solution is to split the project in two, one -model, and > >> another -parser or something. Still, it seems like we're putting a > >> band-aid on the problem by adding more phases. Would it be better to > add > >> control over ordering within a phase? How would that even look in > >> syntax? > >> > >> What do you all think? > >> > >> -j > >> > >> 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. 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 > >>> approach anymore. I'll give you an example: > >>> > >>> Say I have two mojos bound to the package phase, for lack of a better > >>> place. The first takes the tested code, and assembles the directory > >>> structure for the archive. The second creates the archive. If I want > to > >>> replace the first step, I can add a 'skip' flag to it, but I *cannot* > >>> bind a new mojo in its place; any new binding will be added after the > >>> second step. Obviously, it makes no sense to prepare an archive > >>> directory structure *after* the archive is created. > >>> > >>> This is not the first time we've discussed this sort of thing. We have > >>> pre/post phases for setup and tear-down of integration tests, and > should > >>> probably have something similar for unit tests...not to mention, > >>> install, deploy... > >>> > >>> It doesn't seem like a good idea to continue addressing this problem > an > >>> issue at a time in successive Maven releases. Why not make a > reasonable > >>> concession to these use cases, and add pre/post phases to each major > >>> lifecycle phase (those which are themselves pre/post phases are not > what > >>> I consider major). > >>> > >>> I'd like to get this into 2.0.3, since it affects some work I'm doing > >>> for a client. > >>> > >>> What do you all think? > >>> > >>> -john > >>> > >>> - > >>> 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] > > -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom
Re: [proposal] adding pre/post phases for all major lifecycle phases
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 bindings can come from: 1. packaging lifecycle mapping 2. parent POM 3. profiles 4. POM 5. (am I missing something?) So, any syntax would have to support this layering in a way that wouldn't be overly confusing. FWIW, I think I have a band-aid on my client's project that will work for the time being. I'd much rather see this stuff fixed correctly soon, rather than have 10,000 lifecycle phases to support for backward compatibility later on... -john Jesse McConnell wrote: +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 next layer of complexity with some type of ordering maybe.. Providing a mechansim of strict execution ordering inside of a lifecycle phase could address this.. Custom lifecycle phases and goals declared in the pom that can be bound by plugins inside of the pom? (icky) Otherwise it is just too easy to keep adding on layers of pre and post processing :) my 2cents -- to address the axistools pluign, we have discussed this on irc before. it is completely reasonable to compile some classes, generate a wsdl off of those classes for something like a server side wrapping of webservices and then want to generate the client code off of that wsdl.. but what we decided at the time was that it was also ok to just embed that wsdl into the final jar and then in another project process that wsdl out of the dependency jar and generate the client code...perhaps that can be revisited, but the idea of having to support a compile -> generate sources -> compile cycle is not one that has been addressed completely. Especially since I have personally written 4 plugins that needed this type of cycle already, and just swiped code out of the compiler mojo to do it :P jesse On 2/17/06, Piéroni Raphaël <[EMAIL PROTECTED]> wrote: +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. Raphaël 2006/2/17, Emmanuel Venisse <[EMAIL PROTECTED]>: +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 the old suppress-and-augment approach anymore. I'll give you an example: Say I have two mojos bound to the package phase, for lack of a better place. The first takes the tested code, and assembles the directory structure for the archive. The second creates the archive. If I want to replace the first step, I can add a 'skip' flag to it, but I *cannot* bind a new mojo in its place; any new binding will be added after the second step. Obviously, it makes no sense to prepare an archive directory structure *after* the archive is created. This is not the first time we've discussed this sort of thing. We have pre/post phases for setup and tear-down of integration tests, and should probably have something similar for unit tests...not to mention, install, deploy... It doesn't seem like a good idea to continue addressing this problem an issue at a time in successive Maven releases. Why not make a reasonable concession to these use cases, and add pre/post phases to each major lifecycle phase (those which are themselves pre/post phases are not what I consider major). I'd like to get this into 2.0.3, since it affects some work I'm doing for a client. What do you all think? -john - 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] -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build branches/continuum-1.0.x - SUCCESS - update] Fri Feb 17 16:30:00 GMT 2006
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
Re: [proposal] adding pre/post phases for all major lifecycle phases
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 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, I have a list of goals that need met. With the pre/post thing, it is effectively saying "You can have at most three goals met per phase". Another option is to have some sort of consolidation goal that would then be called on a phase, whose definition is an ordered list of goals, I kind of like this better, as it will keep the syntax cleaner, and honestly, how often do you need to cram multiple goals into a phase? One or two at most? Eric On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: 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 that model. Both should fit in generate-sources, but there's a definite order here. Maybe the solution is to split the project in two, one -model, and another -parser or something. Still, it seems like we're putting a band-aid on the problem by adding more phases. Would it be better to add control over ordering within a phase? How would that even look in syntax? What do you all think? -j 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. 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 approach anymore. I'll give you an example: Say I have two mojos bound to the package phase, for lack of a better place. The first takes the tested code, and assembles the directory structure for the archive. The second creates the archive. If I want to replace the first step, I can add a 'skip' flag to it, but I *cannot* bind a new mojo in its place; any new binding will be added after the second step. Obviously, it makes no sense to prepare an archive directory structure *after* the archive is created. This is not the first time we've discussed this sort of thing. We have pre/post phases for setup and tear-down of integration tests, and should probably have something similar for unit tests...not to mention, install, deploy... It doesn't seem like a good idea to continue addressing this problem an issue at a time in successive Maven releases. Why not make a reasonable concession to these use cases, and add pre/post phases to each major lifecycle phase (those which are themselves pre/post phases are not what I consider major). I'd like to get this into 2.0.3, since it affects some work I'm doing for a client. What do you all think? -john - 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]
[jira] Commented: (WAGONFTP-10) NPE in wagon-ftp
[ 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-repository username password solves the problem. Anyway, rather than an NPE we could have a more precise error message :) > 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: Minor > > > When deploying a pom project to an ftp repository there is an NPE see trace > below. > Don't know if it's related but there is no binary ftp client on the machine. > Issuing the same command on a windows machine deploys succesfully. > [INFO] [deploy:deploy] > [INFO] Retrieving previous build number from tux3-ftp-repository > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.wagon.providers.ftp.FtpWagon.openConnection(FtpWagon.java:127) > at > org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) > at > org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:354) > at > org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMetadata(DefaultWagonManager.java:295) > at > org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolveAlways(DefaultRepositoryMetadataManager.java:356) > at > org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolveAlways(DefaultRepositoryMetadataManager.java:310) > at > org.apache.maven.artifact.transform.SnapshotTransformation.resolveLatestSnapshotBuildNumber(SnapshotTransformation.java:158) > at > org.apache.maven.artifact.transform.SnapshotTransformation.transformForDeployment(SnapshotTransformation.java:97) > at > org.apache.maven.artifact.transform.DefaultArtifactTransformationManager.transformForDeployment(DefaultArtifactTransformationManager.java:61) > at > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:68) > at > org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:131) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] > > [INFO] Total time: 1 minute 5 seconds > [INFO] Finished at: Fri Feb 17 17:26:57 CET 2006 > [INFO] Final Memory: 6M/25M > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see:
Re: [proposal] adding pre/post phases for all major lifecycle phases
+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 next layer of complexity with some type of ordering maybe.. Providing a mechansim of strict execution ordering inside of a lifecycle phase could address this.. Custom lifecycle phases and goals declared in the pom that can be bound by plugins inside of the pom? (icky) Otherwise it is just too easy to keep adding on layers of pre and post processing :) my 2cents -- to address the axistools pluign, we have discussed this on irc before. it is completely reasonable to compile some classes, generate a wsdl off of those classes for something like a server side wrapping of webservices and then want to generate the client code off of that wsdl.. but what we decided at the time was that it was also ok to just embed that wsdl into the final jar and then in another project process that wsdl out of the dependency jar and generate the client code...perhaps that can be revisited, but the idea of having to support a compile -> generate sources -> compile cycle is not one that has been addressed completely. Especially since I have personally written 4 plugins that needed this type of cycle already, and just swiped code out of the compiler mojo to do it :P jesse On 2/17/06, Piéroni Raphaël <[EMAIL PROTECTED]> wrote: > > +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. > > Raphaël > > > 2006/2/17, Emmanuel Venisse <[EMAIL PROTECTED]>: > > > > +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 the old > suppress-and-augment > > > approach anymore. I'll give you an example: > > > > > > Say I have two mojos bound to the package phase, for lack of a better > > > place. The first takes the tested code, and assembles the directory > > > structure for the archive. The second creates the archive. If I want > to > > > replace the first step, I can add a 'skip' flag to it, but I *cannot* > > > bind a new mojo in its place; any new binding will be added after the > > > second step. Obviously, it makes no sense to prepare an archive > > > directory structure *after* the archive is created. > > > > > > This is not the first time we've discussed this sort of thing. We have > > > pre/post phases for setup and tear-down of integration tests, and > should > > > probably have something similar for unit tests...not to mention, > > > install, deploy... > > > > > > It doesn't seem like a good idea to continue addressing this problem > an > > > issue at a time in successive Maven releases. Why not make a > reasonable > > > concession to these use cases, and add pre/post phases to each major > > > lifecycle phase (those which are themselves pre/post phases are not > what > > > I consider major). > > > > > > I'd like to get this into 2.0.3, since it affects some work I'm doing > > > for a client. > > > > > > What do you all think? > > > > > > -john > > > > > > - > > > 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] > > > > > -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom
Re: [proposal] adding pre/post phases for all major lifecycle phases
+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, I have a list of goals that need met. With the pre/post thing, it is effectively saying "You can have at most three goals met per phase". Another option is to have some sort of consolidation goal that would then be called on a phase, whose definition is an ordered list of goals, I kind of like this better, as it will keep the syntax cleaner, and honestly, how often do you need to cram multiple goals into a phase? One or two at most? Eric On 2/17/06, John Casey <[EMAIL PROTECTED]> wrote: > > 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 that model. > > Both should fit in generate-sources, but there's a definite order here. > Maybe the solution is to split the project in two, one -model, and > another -parser or something. Still, it seems like we're putting a > band-aid on the problem by adding more phases. Would it be better to add > control over ordering within a phase? How would that even look in > syntax? > > What do you all think? > > -j > > 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. 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 > > approach anymore. I'll give you an example: > > > > Say I have two mojos bound to the package phase, for lack of a better > > place. The first takes the tested code, and assembles the directory > > structure for the archive. The second creates the archive. If I want to > > replace the first step, I can add a 'skip' flag to it, but I *cannot* > > bind a new mojo in its place; any new binding will be added after the > > second step. Obviously, it makes no sense to prepare an archive > > directory structure *after* the archive is created. > > > > This is not the first time we've discussed this sort of thing. We have > > pre/post phases for setup and tear-down of integration tests, and should > > probably have something similar for unit tests...not to mention, > > install, deploy... > > > > It doesn't seem like a good idea to continue addressing this problem an > > issue at a time in successive Maven releases. Why not make a reasonable > > concession to these use cases, and add pre/post phases to each major > > lifecycle phase (those which are themselves pre/post phases are not what > > I consider major). > > > > I'd like to get this into 2.0.3, since it affects some work I'm doing > > for a client. > > > > What do you all think? > > > > -john > > > > - > > 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] > >
[jira] Created: (WAGONFTP-10) NPE in wagon-ftp
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: Minor When deploying a pom project to an ftp repository there is an NPE see trace below. Don't know if it's related but there is no binary ftp client on the machine. Issuing the same command on a windows machine deploys succesfully. [INFO] [deploy:deploy] [INFO] Retrieving previous build number from tux3-ftp-repository [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.wagon.providers.ftp.FtpWagon.openConnection(FtpWagon.java:127) at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) at org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:354) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMetadata(DefaultWagonManager.java:295) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolveAlways(DefaultRepositoryMetadataManager.java:356) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolveAlways(DefaultRepositoryMetadataManager.java:310) at org.apache.maven.artifact.transform.SnapshotTransformation.resolveLatestSnapshotBuildNumber(SnapshotTransformation.java:158) at org.apache.maven.artifact.transform.SnapshotTransformation.transformForDeployment(SnapshotTransformation.java:97) at org.apache.maven.artifact.transform.DefaultArtifactTransformationManager.transformForDeployment(DefaultArtifactTransformationManager.java:61) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:68) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:131) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] [INFO] Total time: 1 minute 5 seconds [INFO] Finished at: Fri Feb 17 17:26:57 CET 2006 [INFO] Final Memory: 6M/25M [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] adding pre/post phases for all major lifecycle phases
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 that model. Both should fit in generate-sources, but there's a definite order here. Maybe the solution is to split the project in two, one -model, and another -parser or something. Still, it seems like we're putting a band-aid on the problem by adding more phases. Would it be better to add control over ordering within a phase? How would that even look in syntax? What do you all think? -j 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. 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 approach anymore. I'll give you an example: Say I have two mojos bound to the package phase, for lack of a better place. The first takes the tested code, and assembles the directory structure for the archive. The second creates the archive. If I want to replace the first step, I can add a 'skip' flag to it, but I *cannot* bind a new mojo in its place; any new binding will be added after the second step. Obviously, it makes no sense to prepare an archive directory structure *after* the archive is created. This is not the first time we've discussed this sort of thing. We have pre/post phases for setup and tear-down of integration tests, and should probably have something similar for unit tests...not to mention, install, deploy... It doesn't seem like a good idea to continue addressing this problem an issue at a time in successive Maven releases. Why not make a reasonable concession to these use cases, and add pre/post phases to each major lifecycle phase (those which are themselves pre/post phases are not what I consider major). I'd like to get this into 2.0.3, since it affects some work I'm doing for a client. What do you all think? -john - 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]
[jira] Closed: (CONTINUUM-496) End Time contains junk value when I forced a build to run
[ 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 > - > > Key: CONTINUUM-496 > URL: http://jira.codehaus.org/browse/CONTINUUM-496 > Project: Continuum > Type: Bug > Components: Core system > Versions: 1.0.2 > Reporter: John Sisson > Assignee: Emmanuel Venisse > Priority: Minor > Fix For: 1.0.3 > > > The following is from the build history when it was building. Note the end > time on the first line: > Dec 1, 2005 10:23:11 PM Dec 31, 1969 4:00:00 PM > BuildingResult > 22Dec 1, 2005 10:00:18 PM Dec 1, 2005 10:06:51 PM Success > Result > 21Dec 1, 2005 7:00:16 PM Dec 1, 2005 7:03:57 PM Success Result > This occurred on http://ci.gbuild.org/continuum/servlet/continuum running a > 1.1-SNAPSHOT. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2082) assembly:assembly doesn't recognize pre-defined assembly types
[ 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 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 > Reporter: Howard M. Lewis Ship > Attachments: pom.xml > > > I'm trying to build a source bundle for uploading to my download site. The > following should work, if I'm folloiwng the documentation property, but > doesn't. > bash-3.00$ mvn assembly:assembly -Dmaven.assembly.descriptorId=src > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'assembly'. > [INFO] > > [INFO] Building Tapestry prop binding extension > [INFO]task-segment: [assembly:assembly] (aggregator-style) > [INFO] > > [INFO] Preparing assembly:assembly > [INFO] > > [INFO] Building Tapestry prop binding extension > [INFO] > > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:compile] > [INFO] Nothing to compile - all classes are up to date > [INFO] [resources:testResources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:testCompile] > [INFO] Nothing to compile - all classes are up to date > [INFO] [surefire:test] > [INFO] Setting reports dir: c:\workspace\tapestry-prop\target/surefire-reports > --- > T E S T S > --- > [surefire] Running org.apache.tapestry.prop.PropertyAccessorBindingFactoryTest > [surefire] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.094 sec > [surefire] Running org.apache.tapestry.prop.PropertyAccessorClassFactoryTest > [surefire] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.187 sec > [surefire] Running org.apache.tapestry.prop.PropertyAccessorSourceTest > [surefire] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.031 sec > Results : > [surefire] Tests run: 10, Failures: 0, Errors: 0 > [INFO] [jar:jar] > [INFO] Building jar: c:\workspace\tapestry-prop\target\tapestry-prop-0.1.1.jar > [INFO] [assembly:assembly] > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] No assembly descriptors found. > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 2 seconds > [INFO] Finished at: Fri Feb 17 08:08:55 PST 2006 > [INFO] Final Memory: 5M/10M > [INFO] > > bash-3.00$ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-2082) assembly:assembly doesn't recognize pre-defined assembly types
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 Reporter: Howard M. Lewis Ship Attachments: pom.xml I'm trying to build a source bundle for uploading to my download site. The following should work, if I'm folloiwng the documentation property, but doesn't. bash-3.00$ mvn assembly:assembly -Dmaven.assembly.descriptorId=src [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'assembly'. [INFO] [INFO] Building Tapestry prop binding extension [INFO]task-segment: [assembly:assembly] (aggregator-style) [INFO] [INFO] Preparing assembly:assembly [INFO] [INFO] Building Tapestry prop binding extension [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Nothing to compile - all classes are up to date [INFO] [surefire:test] [INFO] Setting reports dir: c:\workspace\tapestry-prop\target/surefire-reports --- T E S T S --- [surefire] Running org.apache.tapestry.prop.PropertyAccessorBindingFactoryTest [surefire] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.094 sec [surefire] Running org.apache.tapestry.prop.PropertyAccessorClassFactoryTest [surefire] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.187 sec [surefire] Running org.apache.tapestry.prop.PropertyAccessorSourceTest [surefire] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.031 sec Results : [surefire] Tests run: 10, Failures: 0, Errors: 0 [INFO] [jar:jar] [INFO] Building jar: c:\workspace\tapestry-prop\target\tapestry-prop-0.1.1.jar [INFO] [assembly:assembly] [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] No assembly descriptors found. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Fri Feb 17 08:08:55 PST 2006 [INFO] Final Memory: 5M/10M [INFO] bash-3.00$ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] adding pre/post phases for all major lifecycle phases
+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. Raphaël 2006/2/17, Emmanuel Venisse <[EMAIL PROTECTED]>: > > +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 the old suppress-and-augment > > approach anymore. I'll give you an example: > > > > Say I have two mojos bound to the package phase, for lack of a better > > place. The first takes the tested code, and assembles the directory > > structure for the archive. The second creates the archive. If I want to > > replace the first step, I can add a 'skip' flag to it, but I *cannot* > > bind a new mojo in its place; any new binding will be added after the > > second step. Obviously, it makes no sense to prepare an archive > > directory structure *after* the archive is created. > > > > This is not the first time we've discussed this sort of thing. We have > > pre/post phases for setup and tear-down of integration tests, and should > > probably have something similar for unit tests...not to mention, > > install, deploy... > > > > It doesn't seem like a good idea to continue addressing this problem an > > issue at a time in successive Maven releases. Why not make a reasonable > > concession to these use cases, and add pre/post phases to each major > > lifecycle phase (those which are themselves pre/post phases are not what > > I consider major). > > > > I'd like to get this into 2.0.3, since it affects some work I'm doing > > for a client. > > > > What do you all think? > > > > -john > > > > - > > 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: [proposal] adding pre/post phases for all major lifecycle phases
+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 the old suppress-and-augment approach anymore. I'll give you an example: Say I have two mojos bound to the package phase, for lack of a better place. The first takes the tested code, and assembles the directory structure for the archive. The second creates the archive. If I want to replace the first step, I can add a 'skip' flag to it, but I *cannot* bind a new mojo in its place; any new binding will be added after the second step. Obviously, it makes no sense to prepare an archive directory structure *after* the archive is created. This is not the first time we've discussed this sort of thing. We have pre/post phases for setup and tear-down of integration tests, and should probably have something similar for unit tests...not to mention, install, deploy... It doesn't seem like a good idea to continue addressing this problem an issue at a time in successive Maven releases. Why not make a reasonable concession to these use cases, and add pre/post phases to each major lifecycle phase (those which are themselves pre/post phases are not what I consider major). I'd like to get this into 2.0.3, since it affects some work I'm doing for a client. What do you all think? -john - 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]
[continuum build branches/continuum-1.0.x - SUCCESS - update] Fri Feb 17 15:30:01 GMT 2006
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
[proposal] adding pre/post phases for all major lifecycle phases
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 approach anymore. I'll give you an example: Say I have two mojos bound to the package phase, for lack of a better place. The first takes the tested code, and assembles the directory structure for the archive. The second creates the archive. If I want to replace the first step, I can add a 'skip' flag to it, but I *cannot* bind a new mojo in its place; any new binding will be added after the second step. Obviously, it makes no sense to prepare an archive directory structure *after* the archive is created. This is not the first time we've discussed this sort of thing. We have pre/post phases for setup and tear-down of integration tests, and should probably have something similar for unit tests...not to mention, install, deploy... It doesn't seem like a good idea to continue addressing this problem an issue at a time in successive Maven releases. Why not make a reasonable concession to these use cases, and add pre/post phases to each major lifecycle phase (those which are themselves pre/post phases are not what I consider major). I'd like to get this into 2.0.3, since it affects some work I'm doing for a client. What do you all think? -john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (WAGON-36) An exception is throwed when the http response code is 201
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
Priority: Minor
The put method of the LightweightHttpWagon class throw an exception whener the
http response code is 201. The 201 code indicate the PUT method has completed
successfully in a WebDav environment.
The problem comes from here :
if ( putConnection.getResponseCode() != HttpURLConnection.HTTP_OK )
{
throw new TransferFailedException(
"Unable to transfer file. HttpURLConnection returned the
response code: " +
putConnection.getResponseCode() );
}
An exception is thrown whenever the Http code is different from 200 wich is not
good.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVENUPLOAD-745) xpp3 pull parser
[ 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://jira.codehaus.org/browse/MAVENUPLOAD-745 > Project: maven-upload-requests > Type: Task > Reporter: Michael Böckling > Attachments: xpp3-1.1.3.4.O-bundle.jar, xpp3-min-1.1.3.4.O-bundle.jar, > xpp3-xpath-1.1.3.4.O-bundle.jar, xpp3_min-1.1.3.4.O-bundle.jar, > xpp3_xpath-1.1.3.4.O-bundle.jar > > > Latest release of all 3 versions of the xpp3 pull parser. > Files grabbed from > http://www.extreme.indiana.edu/dist/java-repository/xpp3/jars/. > The current state of the xpp3 versioning is a big mess. Sometimes, the > variation (min, xpath) is added to the version, sometimes used as classifier, > even though the jars have huge differences. > I believe the big differences justify different artifactIds, classifiers are > for similar jars that were built differently (e.g. signed vs. unsigned). > Upload bundles were assembled manually, theres no way I can reproduce that > Ant build (ever). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVENUPLOAD-745) xpp3 pull parser
[ 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.codehaus.org/browse/MAVENUPLOAD-745 > Project: maven-upload-requests > Type: Task > Reporter: Michael Böckling > Attachments: xpp3-1.1.3.4.O-bundle.jar, xpp3-min-1.1.3.4.O-bundle.jar, > xpp3-xpath-1.1.3.4.O-bundle.jar, xpp3_min-1.1.3.4.O-bundle.jar > > > Latest release of all 3 versions of the xpp3 pull parser. > Files grabbed from > http://www.extreme.indiana.edu/dist/java-repository/xpp3/jars/. > The current state of the xpp3 versioning is a big mess. Sometimes, the > variation (min, xpath) is added to the version, sometimes used as classifier, > even though the jars have huge differences. > I believe the big differences justify different artifactIds, classifiers are > for similar jars that were built differently (e.g. signed vs. unsigned). > Upload bundles were assembled manually, theres no way I can reproduce that > Ant build (ever). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build trunk - SUCCESS - update] Fri Feb 17 15:00:00 GMT 2006
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
[jira] Updated: (MNG-2081) Typing error in apt files
[ 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 > Project: Maven 2 > Type: Bug > Components: Documentation: General > Versions: 2.0.1 > Reporter: Vincent Siveton > Fix For: 2.0.3 > Attachments: typing_errors_apt.diff > > > This patch corrects some typing errors in apt files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build branches/continuum-1.0.x - FAILED - update] Fri Feb 17 14:30:00 GMT 2006
Log: http://maven.zones.apache.org/~continuum/logs/branches/continuum-1.0.x/continuum-build-log-20060217.143001.txt
[jira] Commented: (MECLIPSE-8) Suport sources generator in eclipse plugin
[ 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 changed a dependency in the projects pom and started an eclipse:eclipse. Because of the compile error maven2 does not update the classpath. So I have to edit the classpath in the eclipse by hand. In my understanding the classpath should be updated or changed at any time when I start an eclipse:eclipse independend if compile error occured or not. This gives me better chances for bug tracking! > Suport sources generator in eclipse plugin > --- > > Key: MECLIPSE-8 > URL: http://jira.codehaus.org/browse/MECLIPSE-8 > Project: Maven 2.x Eclipse Plugin > Type: Bug > Versions: 2.0 > Reporter: Gilles Scokart > Assignee: fabrizio giustina > Fix For: 2.1 > > > The current eclipse plugin doesn't have suport for code generation like Maven > 1 (see http://maven.apache.org/maven-1.x/reference/plugins/eclipse/). > In maven 2, its probably simpler. The eclipse plugin in should only launch > the build cycle up to process-test-resources. If any plugin is executed in > the source generation or test source generation phase, those plugins will > automatically add the directory to the list of source directory (as described > in http://maven.apache.org/guides/mini/guide-generating-sources.html). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (DOXIA-51) RtfSink supports only ".ppm" image type in figureGraphics()
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 Reporter: Vincent Siveton Need to update the writeImage() method to support more image types -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DOXIA-50) Improve the AptParser class
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 patch provides some improvements for the AptParser: * support of the pagebreak, ie ^L * support of tableHeaderCell() call * improve the tableCaption() call -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ 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 and a pom-server.xml. The difference between the two is the pom.xml doesn't contain dependencies for the projects that are in the eclipse workspace. Is there a better solution? > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Components: Dependency Resolver > Versions: 0.0.4 > Reporter: Leonardo Quijano Vincenzi > Assignee: Eugene Kuleshov > Fix For: 1.0.0 > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-2081) Typing error in apt files
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.diff This patch corrects some typing errors in apt files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPJBOSS-24) 'maven jboss' goal when run with Maven 1.1. beta 2 generates bad run.bat and shutdown.bat files
[ 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 you want. Otherwise we recommand to use the maven plugin for cargo which support a lot of containers : http://cargo.codehaus.org/ http://cargo.codehaus.org/Maven1+plugin > 'maven jboss' goal when run with Maven 1.1. beta 2 generates bad run.bat and > shutdown.bat files > > > Key: MPJBOSS-24 > URL: http://jira.codehaus.org/browse/MPJBOSS-24 > Project: maven-jboss-plugin > Type: Bug > Reporter: Manisha Sur > > > 'maven jboss' goal when run with Maven 1.1. beta 2 generates bad run.bat and > shutdown.bat files . > so before running 'maven jboss:start' , they should be corrected. > while maven 1.0.2 generated correct bat files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (MPJBOSS-24) 'maven jboss' goal when run with Maven 1.1. beta 2 generates bad run.bat and shutdown.bat files
[ 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' goal when run with Maven 1.1. beta 2 generates bad run.bat and > shutdown.bat files > > > Key: MPJBOSS-24 > URL: http://jira.codehaus.org/browse/MPJBOSS-24 > Project: maven-jboss-plugin > Type: Bug > Reporter: Manisha Sur > > > 'maven jboss' goal when run with Maven 1.1. beta 2 generates bad run.bat and > shutdown.bat files . > so before running 'maven jboss:start' , they should be corrected. > while maven 1.0.2 generated correct bat files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MRM-38) add a background task scheduler
[ 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.codehaus.org/browse/MRM-38 > Project: Maven Repository Manager > Type: New Feature > Components: scheduling > Reporter: Brett Porter > Assignee: John Tolentino > Fix For: 1.0-alpha-1 > Attachments: MRM-38-maven-repository-webapp.diff, > maven-repository-webapp.diff > > Time Spent: 6 hours, 3 minutes >Remaining: 0 minutes > > we need to be able to schedule tasks. We should use quartz, and reuse code > from Continuum that does similarly. > There needs to be a way to add/remove/configure scheduled tasks such as > indexing, report execution and syncing -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPIR-30) The automatically generated documentation should identify the project's group id, artifact id, and maybe version
[ 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
>
>
> Key: MPIR-30
> URL: http://jira.codehaus.org/browse/MPIR-30
> Project: Maven 2.x Project Info Reports Plugin
> Type: Improvement
> Reporter: Howard M. Lewis Ship
> Fix For: 2.0
>
>
> The standard set of reports, i.e., ${reports}, should automatically
> generate documentation identitying the group id and artifact id, as this is
> critical to making use of a maven project as a dependency. Perhaps this could
> go on the dependencies page.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (WAGON-35) wagon doesn't support site:deploy via ftp
[ 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: WAGON-35 > URL: http://jira.codehaus.org/browse/WAGON-35 > Project: wagon > Type: Bug > Versions: 1.0-alpha-6 > Environment: maven 2.0.2, win xp > Reporter: Howard M. Lewis Ship > Assignee: Brett Porter > Attachments: pom.xml > > > I'm attempting to deploy my site via ftp; my hosting only allows FTP access, > no SSH, so I'm stuck using FTP. > I get the following failure: > bash-3.00$ mvn site:deploy > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'site'. > [INFO] > > [INFO] Building Tapestry prop binding extension > [INFO]task-segment: [site:deploy] > [INFO] > > [INFO] [site:deploy] > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Wagon protocol 'ftp' doesn't support directory copying > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Thu Feb 16 18:42:50 PST 2006 > [INFO] Final Memory: 4M/7M > [INFO] > > bash-3.00$ > I've attached my pom -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (MPIR-30) The automatically generated documentation should identify the project's group id, artifact id, and maybe version
[ 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)
Key: MPIR-30 (was: MNG-2080)
Project: Maven 2.x Project Info Reports Plugin (was: Maven 2)
> The automatically generated documentation should identify the project's group
> id, artifact id, and maybe version
>
>
> Key: MPIR-30
> URL: http://jira.codehaus.org/browse/MPIR-30
> Project: Maven 2.x Project Info Reports Plugin
> Type: Improvement
> Reporter: Howard M. Lewis Ship
>
>
> The standard set of reports, i.e., ${reports}, should automatically
> generate documentation identitying the group id and artifact id, as this is
> critical to making use of a maven project as a dependency. Perhaps this could
> go on the dependencies page.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-2079) scm plugin cannot checkout nested modules
[ 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 just the presence of this report is going to help a whole lot. Time well spent. > scm plugin cannot checkout nested modules > - > > Key: MNG-2079 > URL: http://jira.codehaus.org/browse/MNG-2079 > Project: Maven 2 > Type: Improvement > Components: Reactor and workspace, Bootstrap & Build > Versions: 2.0.2 > Environment: maven 2 on linux > Reporter: Dan Allen > > > Maven2 doesn't seem to be smart enough to recognize that it is being told to > checkout a project that has sub-modules and that it needs to get the pom.xml > files for those modules from the scm url located in the top level pom. > Commands speak louder than words, so I will cite an example. Say you need to > checkout the continuum code, but you would like to do it via maven scm > (which, by the way, is required to get continuum set up using your project, > which is the purpose of this issue) > wget http://svn.apache.org/repos/asf/maven/continuum/trunk/pom.xml > mvn scm:checkout > The result: > Reason: Could not find the model file > '/home/dallen/tmp/checkout/continuum/continuum-api/pom.xml'. > [INFO] > > [INFO] Trace > org.apache.maven.reactor.MavenExecutionException: Could not find the model > file '/home/dallen/tmp/checkout/continuum/continuum-api/pom.xml'. > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:359) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:276) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.project.ProjectBuildingException: Could not find > the model file '/home/dallen/tmp/checkout/continuum/continuum-api/pom.xml'. > at > org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1061) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFile(DefaultMavenProjectBuilder.java:291) > at > org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:276) > at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:509) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:441) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:485) > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:345) > ... 11 more > Caused by: java.io.FileNotFoundException: > /home/dallen/tmp/checkout/continuum/continuum-api/pom.xml (No such file or > directory) > at java.io.FileInputStream.open(Native Method) > at java.io.FileInputStream.(FileInputStream.java:106) > at java.io.FileReader.(FileReader.java:55) > at > org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1056) > And I promptly say, "of course you can't, because you haven't checked it out > yet!" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MSITE-92) site:stage fails, goal not found
[ 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:stage fails, goal not found > > > Key: MSITE-92 > URL: http://jira.codehaus.org/browse/MSITE-92 > Project: Maven 2.x Site Plugin > Type: Bug > Environment: Maven 2.0.2 > Reporter: Howard M. Lewis Ship > Assignee: Brett Porter > > > The documentation for "site:stage" is unclear; it appears to be something > that will build my site to a particular directory? In trying to test it out, > to see what it does, I found out that it does not work. > bash-3.00$ mvn site:stage > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'site'. > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Required goal not found: site:stage > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: < 1 second > [INFO] Finished at: Thu Feb 16 18:57:01 PST 2006 > [INFO] Final Memory: 2M/5M > [INFO] > > bash-3.00$ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVEN-1748) 'maven jboss' goal when run with Maven 1.1. beta 2 generates bad run.bat and shutdown.bat files
'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 Type: Bug Reporter: Manisha Sur 'maven jboss' goal when run with Maven 1.1. beta 2 generates bad run.bat and shutdown.bat files . so before running 'maven jboss:start' , they should be corrected. while maven 1.0.2 generated correct bat files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MJAVADOC-58) content should not be included in apostrophes on the commandline
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 Versions: 2.0-beta-3 Environment: W2k Reporter: Rik Graetke We have written our own doclet that needs additional parameter/value-pairs on the command-line, which after all needs to look like this: javadoc -J-Xmx300m -J-Xms40m -J-ea -doclet de.mobilcom.javadoc.McDoclet -globaltagoverview 'system.property:w:2:System Prop.' ... I'm trying to configure javadoc-Plugin like this: ... de.mobilcom.javadoc.McDoclet -globaltagoverview 'system.property:w:2:System Prop.' ... Running this, i receive an javadoc error "invalid flag: -globaltagoverview" Examining the options-file shows, that resolved to: '-globaltagoverview 'system.property:w:2:System Prop.' ' on the command line which in fact is not working after manually removing the apostrophes everything is OK when running it as -globaltagoverview 'system.property:w:2:System Prop.' Additional Problem: trying -J-ea puts the '-J-ea ' in the Option-File which as far as i know is not working for J-Options -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build branches/continuum-1.0.x - SUCCESS - update] Fri Feb 17 10:30:00 GMT 2006
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
[jira] Commented: (MAVENUPLOAD-742) Please upload maven-qalab-plugin
[ 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 point me at some docs, or explain to me in words a simple person would understand what it is you want. dave > Please upload maven-qalab-plugin > > > Key: MAVENUPLOAD-742 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-742 > Project: maven-upload-requests > Type: Task > Reporter: Dave Sag > Attachments: maven-qalab-plugin-2.0-bundle.jar > > > this plugin provides the basic merge and movers mojos and main and movers > reports taking input from checkstyle, PMD and findbugs and reporting > statistical quality data over the life of the project. > it's a reworking of the maven 1 plugin for maven 2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-2079) scm plugin cannot checkout nested modules
[ 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 -N > scm plugin cannot checkout nested modules > - > > Key: MNG-2079 > URL: http://jira.codehaus.org/browse/MNG-2079 > Project: Maven 2 > Type: Improvement > Components: Reactor and workspace, Bootstrap & Build > Versions: 2.0.2 > Environment: maven 2 on linux > Reporter: Dan Allen > > > Maven2 doesn't seem to be smart enough to recognize that it is being told to > checkout a project that has sub-modules and that it needs to get the pom.xml > files for those modules from the scm url located in the top level pom. > Commands speak louder than words, so I will cite an example. Say you need to > checkout the continuum code, but you would like to do it via maven scm > (which, by the way, is required to get continuum set up using your project, > which is the purpose of this issue) > wget http://svn.apache.org/repos/asf/maven/continuum/trunk/pom.xml > mvn scm:checkout > The result: > Reason: Could not find the model file > '/home/dallen/tmp/checkout/continuum/continuum-api/pom.xml'. > [INFO] > > [INFO] Trace > org.apache.maven.reactor.MavenExecutionException: Could not find the model > file '/home/dallen/tmp/checkout/continuum/continuum-api/pom.xml'. > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:359) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:276) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.project.ProjectBuildingException: Could not find > the model file '/home/dallen/tmp/checkout/continuum/continuum-api/pom.xml'. > at > org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1061) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFile(DefaultMavenProjectBuilder.java:291) > at > org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:276) > at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:509) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:441) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:485) > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:345) > ... 11 more > Caused by: java.io.FileNotFoundException: > /home/dallen/tmp/checkout/continuum/continuum-api/pom.xml (No such file or > directory) > at java.io.FileInputStream.open(Native Method) > at java.io.FileInputStream.(FileInputStream.java:106) > at java.io.FileReader.(FileReader.java:55) > at > org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1056) > And I promptly say, "of course you can't, because you haven't checked it out > yet!" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-745) xpp3 pull parser
[ 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 wondered what obscure versions were addressed in ibiblio with those -1.1.3.4-RCx releases. > xpp3 pull parser > > > Key: MAVENUPLOAD-745 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-745 > Project: maven-upload-requests > Type: Task > Reporter: Michael Böckling > Attachments: xpp3-1.1.3.4.O-bundle.jar, xpp3-min-1.1.3.4.O-bundle.jar, > xpp3-xpath-1.1.3.4.O-bundle.jar > > > Latest release of all 3 versions of the xpp3 pull parser. > Files grabbed from > http://www.extreme.indiana.edu/dist/java-repository/xpp3/jars/. > The current state of the xpp3 versioning is a big mess. Sometimes, the > variation (min, xpath) is added to the version, sometimes used as classifier, > even though the jars have huge differences. > I believe the big differences justify different artifactIds, classifiers are > for similar jars that were built differently (e.g. signed vs. unsigned). > Upload bundles were assembled manually, theres no way I can reproduce that > Ant build (ever). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1703) is not propagated to child POMs
[ 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-1703 > URL: http://jira.codehaus.org/browse/MNG-1703 > Project: Maven 2 > Type: Bug > Components: POM > Versions: 2.0 > Reporter: Yann Le Du > Assignee: Edwin Punzalan > Fix For: 2.0.3 > Attachments: MNG-1703-maven-project.patch > > > section in isn't propagated to child POMs (as > is). > The workaround is to use with true > Is this on purpose ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNGECLIPSE-75) Update source folders action should set default output folder
[ 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 related. Yes, after changing the source folders, I can do an "Update source folders". > Update source folders action should set default output folder > - > > Key: MNGECLIPSE-75 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-75 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Versions: 0.0.5 > Environment: Linux. JDK 1.5. XmlBeans 2.x. > Reporter: Jimisola Laursen > Assignee: Eugene Kuleshov > Attachments: MNGECLIPSE-75.tar.gz, mngeclipse-75-xmlbeans-testcase.zip > > > I have a problem with Maven2, XmlBeans Maven Plugin and this plugin (Eclipse > Maven Plugin). However, I do believe that the problem will exist when > generating sources in other ways as well. I assume that you are familiar > with XmlBeans (if not, it's Java Binding tools that creates Java classes for > an XML Schema). > In my project I use XmlBeans when performing unit tests. Hence, the XmlBeans > Maven Plugin generates Java code under /target/test-xmlbeans-source. The > actual problem is that Eclipse needs the generated Java code otherwise it > generates errors since it can't find the classes used by the unit tests. I > want the Maven plugin to add classes of auto-generated source code to Eclipse > class paths (dependency). Is there a solution for this? > Like I hinted above this is not a XmlBeans specific problem as a project can > have other tools generating code using e.g. XSLT, AntLR etc (my project uses > XSLT as well). There are many advantages using Maven and two important ones > are with it and Eclipse: > 1) the project is built the same (i.e. using the exact same setup of > libraries, library versions etc) whether is it inside or outside Eclipse > 2) all developers have the exact same setup (same version of dependencies etc) > Are there any other known (potential) issues preventing Eclipse and Maven > from working seamlessly? > Can the Eclipses built-in compiler cause problems? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
