Re: Discussion for issue MNG-2546 (Eclipse/OSGi Dependencies)
On 9/5/06, Wendell Beckwith <[EMAIL PROTECTED]> wrote: On 9/4/06, Brett Porter <[EMAIL PROTECTED]> wrote: > > If you've done the work, go ahead and submit a patch. I think I'll > find the code easier to read than this mail :) Done. Yeah, the email was verbose but the code changes were simple once I found where the reactor was located. I think we definitely need a solution to being able to know in > advance of the build, how all the source directories, etc will be > bound in (Milos has been asking for this in the Netbeans integration > for some time too). Hopefully this will help. I can imagine wanting to plug into maven before it gets going and after it has stopped. The current patch only handles the initialization phase but it would not be too much more to add a finalization phase too. I doubt it would be possible/practical to try and know how everything will eventually shake out ahead of time. Instead it would be more practical to allow plugins/external entities to register as framework listeners and notify them of certain events. Thus if a new source root is added the IDE could be informed and it could take the appropriate action, whatever that is. Wb I'm not sure I understand how the MNG-2546 issue is related to what I need in the IDE. let me reiterate my requirements. 1. find out what the source roots are (even if not existing yet) for a given project without executing it. That sort of points in the directtion of declaratively marking some mojo parameters as source roots and making it available from the mojo descriptions. 2. plugging into the maven execution cycle from the IDE is already possible. A simple method is to register the loggers, a more advanced one is to replace plexus components with custom, proxying versions of my own that do additional bookkeeping. It wouldn't hurt to make it easier but it's generally possible. 3. I want to keep the actual building as separated from the IDE environment as possible. This might sound contrary to 2. but is actually complimentary. I want a peek tool into the project definition (2), but the actual process of execution shall be untouched(3). Additionally one might want to have multiple versions of maven to execute in the IDE environment at once (in case of some binary incompatibility). That's where having the IDE's build to depend on one particular version could hurt. Milos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Anyway to call a goal from a mojo?
Here is the snippet I was talking about: http://www.nabble.com/m2%3A-Delegating-to-other-Mojo-tf1695516.html#a4602520 I haven't used @execute, but if it does the job - thats neat! Cheers, Rahul - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: "Maven Developers List" Sent: Tuesday, September 05, 2006 4:57 AM Subject: Re: Anyway to call a goal from a mojo? Code samples are always nice :-) I did also run into '@execute goal=install' which appears to invoke the 'install' goal of my plugin before the goal will execute. This might work for my needs, though I'm not sure exactly how the execution configuration relates to mojo's invoked in this manner. Is this "feature" documented somewhere? --jason On Sep 3, 2006, at 8:47 PM, Rahul Thakur wrote: You can use MavenEmbedder to do this. Pretty sure there was some example code floating on the user@ or dev@ list. I wrote a delegate mojo a while ago that does something similar but don't have the code handy here, but I can dig later today if you are keen at looking at it. Cheers, Rahul Jason Dillon wrote: Is there any (easy) way to call a goal from a mojo? I've got a geronimo:install goal, that does some assembly unpacking, and a geronimo:start goal which starts up the server. geronimo:start really needs to call geronimo:install before it runs. Is there an easy way to do this? The only way I can think to share this code, is to add more abstract classes to hold the methods... but that gets messy fast. Any ideas? --jason - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where is the KEYS file that I can add my key to?
Is this documented somewhere where we can point new committers to? -Lukas Jason van Zyl wrote: On 28 Aug 06, at 4:04 PM 28 Aug 06, Dennis Lundberg wrote: I'll put together a draft for review. Dennis, I made a project wide module and placed the KEYS file in it along with a script to sync the KEYS to the right place on the server: http://svn.apache.org/repos/asf/maven/project/ Everyone involved in a Maven project has access and should modify the KEYS file there and then sync it. Thanks, Jason van Zyl [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: Welcome to new committers!
A late welcome from me too! I'm looking forward to working with you guys, if you have any questions/problems, you know who to ask! -Lukas Arnaud HERITIER wrote: Welcome guys ! I'm so happy ! We double the m1 team ;-) cheers ! Arnaud On 8/30/06, Jimisola Laursen <[EMAIL PROTECTED]> wrote: Haha :) Do you have anything against Germans? :) Regards, Jimisola PS. My name doesn't show it, but I'm also Swedish DS. Joakim Erdfelt-2 wrote: > > Thanks! > > btw, it's "Joakim Erdfelt" not "Joakime Erdfeldt" > > I'm Swedish, not German. ;-) > > - Joakim Erdfelt > > Jason van Zyl wrote: >> Hi, >> >> We would like to welcome Joakime Erdfeldt, Shinobu Kawai, and Jeff >> Jensen to the Maven Team! >> >> Joakime will be working on Continuum and Maven 2.x plugins, Shinobu >> and Jeff will be working in Maven 1.x land. >> >> Thanks for your contributions thus far and have fun hacking on Maven! >> (We hope to get far more out of you now that you are committers! :-)) >> >> The Maven Team >> >> >> >> >> - >> 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] > > > -- View this message in context: http://www.nabble.com/Welcome-to-new-committers%21-tf2192516.html#a6067928 Sent from the Maven Developers forum at Nabble.com. - 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: [m1] Please test maven eclipse plugin 1.11.1
I have scheduled MPECLIPSE-102 for 1.11.1 still, please have a look at it (I'm not using eclipse). Just unschedule if you think it's too much trouble. -Lukas Stephane Nicoll wrote: Hi, The maven eclipse plugin 1.11.1 is ready to be released (to be included in m1.1 final). A snapshot has been deployed [1]. The changes are available in Jira[2] Thanks, Stéphane [1] http://people.apache.org/repo/m1-snapshot-repository/maven/plugins/maven-eclipse-plugin-1.11.1-SNAPSHOT.jar [2] http://jira.codehaus.org/browse/MPECLIPSE?report=com.atlassian.jira.plugin.system.project:roadmap-panel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reporting web user interface
I'll leave -77 to last, but I'm starting work on this. So I'll do -83 and some backend stuff (-161, -162), as well as -143 and maybe -82. Basically what I'm thinking is that there will be a component - the reporting manager, that: * is the central place to log issues that occur outside of general reporting (eg, the indexer can find problems that reports wouldn't) * tracks all the issues, and persists them to disk at the root of the repository, loading them back up on startup * executes reports when asked on a schedule and controls what reports are available Let me know if you've made any progress! Cheers, Brett On 01/09/2006, at 6:35 PM, Franz Allan Valencia See wrote: On 8/31/06, Brett Porter <[EMAIL PROTECTED]> wrote: On 01/09/2006, at 12:54 AM, Franz Allan Valencia See wrote: > Good day to you, Brett, > >> There's lot of things to be done. >> >> - implement triggering of the reports and recording of the results > > do we now have designs on what events triggers what actions? ^_^ The triggering at present is all time based - the scheduler will kick off a task which scans the repo and checks for a set of issues (in the same way as the indexing works, basically). However, I think this is a dependant task to do first: - MRM-83 (change the reports to take a listener) > >> - implement the web actions for those screens > > by "those screens" are you referring to the repoman-site itself? or > just the reports.html...if it's just reports.html, which web actions > were you referring to? They aren't obvious because of the link colouring, but there's a "repair" link in some cases. It should also be possible to navigate to the artifact and possibly other actions. > >> - implement ways to quick fix problems found in the reports > > Absolutely no idea as to what you have in mind for this ^_^ I think a report should have these methods: boolean canQuickFix( Result result ); void performQuickFix( Result result ); So, for example, if the checksum is incorrect, this can be fixed for any file by recalculating and saving the checksum. > >> >> Any in particular that you are interested in? >> >> Cheers, >> Brett >> > > Currently, my interests are leaning towards the triggers ^_^ That should be fairly straightforward to set up so its a good place to start. Thanks! > > Thanks a bunch, > Franz Since, the first one depends on MRM-83 (and someone already took responsibility in it), i guess i'll start first with the implementation of the web actions ^_^ btw, when one navigates to the other artifacts, what should be seen, the [1] page, or something like [2] or what? ^_^ Sorry if i have too many questions. I am interested in working with archiva, but i only know a small amount about it. btw, where can i see the details regarding this project, i mean, where it's heading and where it is right now ^_^ Thanks a bunch, Franz [1] http://people.apache.org/~brett/repoman-site/artifact.html [2] http://snapshots.repository.codehaus.org/
Re: Discussion for issue MNG-2546 (Eclipse/OSGi Dependencies)
On 05/09/2006, at 11:32 AM, Wendell Beckwith wrote: I can imagine wanting to plug into maven before it gets going and after it has stopped. The current patch only handles the initialization phase but it would not be too much more to add a finalization phase too. I doubt it would be possible/practical to try and know how everything will eventually shake out ahead of time. Instead it would be more practical to allow plugins/external entities to register as framework listeners and notify them of certain events. Thus if a new source root is added the IDE could be informed and it could take the appropriate action, whatever that is. I think the solution we talked about was a "dry run" execution through the embedder. All the plugins get run, but they don't do anything except populate the parameters they would given the configuration they are provided. Would require a decent change to the plugin API though! - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion for issue MNG-2546 (Eclipse/OSGi Dependencies)
On 9/4/06, Brett Porter <[EMAIL PROTECTED]> wrote: If you've done the work, go ahead and submit a patch. I think I'll find the code easier to read than this mail :) Done. Yeah, the email was verbose but the code changes were simple once I found where the reactor was located. I think we definitely need a solution to being able to know in advance of the build, how all the source directories, etc will be bound in (Milos has been asking for this in the Netbeans integration for some time too). Hopefully this will help. I can imagine wanting to plug into maven before it gets going and after it has stopped. The current patch only handles the initialization phase but it would not be too much more to add a finalization phase too. I doubt it would be possible/practical to try and know how everything will eventually shake out ahead of time. Instead it would be more practical to allow plugins/external entities to register as framework listeners and notify them of certain events. Thus if a new source root is added the IDE could be informed and it could take the appropriate action, whatever that is. Wb
Re: svn commit: r439352 - in /maven/components/trunk: ./ maven-artifact-manager/ maven-artifact-manager/src/main/java/org/apache/maven/artifact/repository/metadata/ maven-artifact-manager/src/test/jav
On 02/09/2006, at 1:29 AM, [EMAIL PROTECTED] wrote: Modified: maven/components/trunk/maven-artifact-manager/pom.xml URL: http://svn.apache.org/viewvc/maven/components/trunk/maven- artifact-manager/pom.xml?rev=439352&r1=439351&r2=439352&view=diff == --- maven/components/trunk/maven-artifact-manager/pom.xml (original) +++ maven/components/trunk/maven-artifact-manager/pom.xml Fri Sep 1 08:29:52 2006 @@ -54,5 +54,9 @@ org.apache.maven.wagon wagon-provider-api + + easymock + easymock + I didnt think depMgmt managed scopes? +private static final class TestRepoMetadata +extends AbstractRepositoryMetadata Why was this needed when you are mocking the other things? Not sure I understand. + +public class MockManager I'm not sure of the value of this, but it's an interesting approach. Shouldn't it be separate to artifact-manager though? +public class TestFileManager I don't understand this code either. For the user, this seems to be just as verbose as: File f = File.createTempFile( ... ); f.deleteOnExit(); Most of the rest seems to duplicate FileUtils code. If we're going to start assembling some test utilities, that's cool, but we should put it in shared and agreed we are going to use it consistently. One of the pitfalls of testing the current codebase is that you don't know which to use, and where (especially when it comes to plugin and integration testing) - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion for issue MNG-2546 (Eclipse/OSGi Dependencies)
If you've done the work, go ahead and submit a patch. I think I'll find the code easier to read than this mail :) I think we definitely need a solution to being able to know in advance of the build, how all the source directories, etc will be bound in (Milos has been asking for this in the Netbeans integration for some time too). Hopefully this will help. - Brett On 05/09/2006, at 6:21 AM, Wendell Beckwith wrote: I was hoping to get some discussion going about http://jira.codehaus.org/browse/MNG-2546. For handling eclipse plugins this is a big issue. I really see this as extending the support that maven provides to single project builds to multi-project builds. A lot of plugins dynamically add information to a MavenProject instance such as new source paths, dependencies, resources, etc. These plugins can typically do their job by binding to a phase before the information is needed. Plugins functioning in multi-project reactor builds need the same thing but maven does not provide a phase to bind to before the reactor build is kicked off. I have fixed this for the maven 2.1 trunk and passed all 101 tests. Do I need to submit a patch now or is this consider blasphemous and it needs to be aired out a little bit in discussion? For those who are interested I extended the LifecycleExecuter interface and added a method that will do reactor builds for a single phase, super-init. The ReactorManager picked up a new method, sortProjects(List projects) that sorts the projects and I removed the final modifier from the sorter attribute because if the super-init phase is executed then we need the ability to reset the field with a new ProjectSorter instance. The Lifecycle class has methods getPhases() and getDefaultPhases(), however the getPhases() method would create and set a new empty list if the attribute was null while the getDefaultPhases() method would just return null. I changed the getDefaultPhases() method to work similar and it now creates and sets an empty map if the attribute is null. The DefaultLifecycleExecutor was changed to extend my LifecycleExecutor extension and implement the executeSuperInit() method. The executeSuperInit() method creates a single goal, super-init, and then executes it. A element with the id, super-init and a single phase also named super-init was added to the components.xml. The phase has no plugin bindings. Finally the DefaultMaven class has picked up a method to check if any projects in the reactor has plugin execution bindings to the super-init phase. If so then the LifecycleExecutor is called to execute the super-init phase and then if there are no errors the reactor's projects are resorted and normal reactor processing kicks in. This is all 100% backwards compatible because unless you bind a plugin to the phase then the extra processing won't happen and it will be business as usual. Right now this is working great, but is it a direction maven intends to support? Wb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RANT] Maven is both heaven and hell
On 05/09/2006, at 2:41 AM, Wendell Beckwith wrote: That's a surprising admission sense I never would have thought of maven development as being stalled. Thank goodness Google gives me a couple gigs for email otherwise I would have to dump email every other day it seems. Well, the project is certainly moving along, but the work on the core itself has been pushed down the list a little while we sorted out a plan for documentation and getting some more stability from the plugins. I just looked at the roadmap and there are 578 issues combined between maven 2.0.5 and 2.1, approx. 41.2 issues per listed dev assignee. For 2 releases that's not an insane #. So from your standpoint we should just checkout the trunk and go to town submitting patches? Sure! Just keep in touch with the list about what you are working on it and ping us for feedback regularly. If there are eyeballs on it, patches can get applied faster. An important thing, even if it slows down the rate of progress, is to improve the tests and docs along with each piece of work. It's something we are definitely going to have to attend to as we pick up work on it. I was really spinning my wheels last week, but I've gotten past that now and opened the Jira issues. However, if I just blow off the docs now, then I'm repeating history. So, I'll start submitting patches for issues that are all ready in Jira. It can help me get better acclimated to how you all function. Ok, great. Let us know if there's anything we can do to help you dive in, and thanks for doing so! Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r440170 - /maven/components/trunk/maven-artifact-manager/pom.xml
I think it's just a limitation in how depMgmt is handled in the bootstrap. - Brett On 05/09/2006, at 6:24 AM, [EMAIL PROTECTED] wrote: Author: fgiust Date: Mon Sep 4 13:24:31 2006 New Revision: 440170 URL: http://svn.apache.org/viewvc?view=rev&rev=440170 Log: make continuum stop complaining about a missing version for easymock for now... could anybody make it build the parent pom? Modified: maven/components/trunk/maven-artifact-manager/pom.xml Modified: maven/components/trunk/maven-artifact-manager/pom.xml URL: http://svn.apache.org/viewvc/maven/components/trunk/maven- artifact-manager/pom.xml?view=diff&rev=440170&r1=440169&r2=440170 == --- maven/components/trunk/maven-artifact-manager/pom.xml (original) +++ maven/components/trunk/maven-artifact-manager/pom.xml Mon Sep 4 13:24:31 2006 @@ -57,6 +57,7 @@ easymock easymock + 1.2_Java1.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release of maven-changes-plugin
Jochen Wiedmann wrote: Hi, Hi all, Sorry for being quiet for a while. I've just recovered from a crashed system disk, but am now back with e-mail again. Lots to catch up on... about two months ago, a vote was held for releasing the maven-changes-plugin. (See http://marc.theaimsgroup.com/?t=11538500061&r=1&w=2 That vote was to move the plugin out of the sandbox. So a new vote will need to be held to release the plugin. Some issues were raised, in particular concerning the maven-changelog-plugin (as opposed to the maven-changes-plugin) and the conclusion was to defer the release. Currently, a single issue is open (MCHANGES-50), which I was never able to reproduce and which shouldn't be called a blocker anyways, at least IMO. My question is, whether it wouldn't be possible to release the thing finally? If it helps, I'd be glad to do the required work. There are a few other things that needs to be fixed before a release can be done. I've collected some stuff on the user-list. Will go through it and put it into JIRA. Jochen -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: http://jira.codehaus.org/browse/SUREFIRE-53
Hi Kenney On 9/4/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote: There are 2 classloaders created - one for surefire itself, containing surefire code and the testing framework; the second one contains only the test dependencies from the POM. If your annotations can't be found, they're missing from the project test path. Or the two classloaders described above aren't linked. I can confirm that it doesn't look so easy. It someway works when using the system classloader, but it currently fails with any other combination. The usual result is that surefire can't find tests (if the annotation class is loaded by both classloader or only from the test classloader) or also a ClassNotFound exception when testng is loaded only by the project classloader. If it worked before, it shouldn't have, because the root classloader shouldn't contain the testng annotations. I agree, it sholdn't... but as said I could not find a different solution to make it work too. Could you provide a unit test? At the moment you can run integration tests in maven-surefire-plugin for a quick spin. You can try running mvn test on maven-surefire-plugin/src/it/test8 for example. At the moment it works, the result is: Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.03 sec ... if you remove the root classloader the result is: Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.041 sec (note that it will not fail... if you have any suggestion on how to check this result please give us a hint) Another strange thing that I noticed is that at the moment tests are only found in projects which depends on TestNG 5.1 (the same version used in the surefire provider). maven-surefire-plugin/src/it/test6 is exactly the same as test8 but declares a dependency on TestNG 5.0.1 and it doesn't work fabrizio -- Kenney Jesse Kuhnert wrote: > Applying the patch mentioned has made running annotation based testng tests > b0rken. Ie before it was loading classes using a context of system class > loader. I've fixed this locally by calling createClassLoader(classpathurls, > childdelegation, true) (which uses system class loader by default) instead > of createClassLoader(classpathurls, null, childdelegation, true). > > The recent application of old patches is definitely appreciated, but things > like this make me nervous for the future. There ~has~ to be a reasonable > way > to run unit tests against surefire that assert things aren't broken...The > logic of classloader dependencies is too fragile to not have tests... > > Sorry, I shouldn't be telling you guys what to do.. > - 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]
Discussion for issue MNG-2546 (Eclipse/OSGi Dependencies)
I was hoping to get some discussion going about http://jira.codehaus.org/browse/MNG-2546. For handling eclipse plugins this is a big issue. I really see this as extending the support that maven provides to single project builds to multi-project builds. A lot of plugins dynamically add information to a MavenProject instance such as new source paths, dependencies, resources, etc. These plugins can typically do their job by binding to a phase before the information is needed. Plugins functioning in multi-project reactor builds need the same thing but maven does not provide a phase to bind to before the reactor build is kicked off. I have fixed this for the maven 2.1 trunk and passed all 101 tests. Do I need to submit a patch now or is this consider blasphemous and it needs to be aired out a little bit in discussion? For those who are interested I extended the LifecycleExecuter interface and added a method that will do reactor builds for a single phase, super-init. The ReactorManager picked up a new method, sortProjects(List projects) that sorts the projects and I removed the final modifier from the sorter attribute because if the super-init phase is executed then we need the ability to reset the field with a new ProjectSorter instance. The Lifecycle class has methods getPhases() and getDefaultPhases(), however the getPhases() method would create and set a new empty list if the attribute was null while the getDefaultPhases() method would just return null. I changed the getDefaultPhases() method to work similar and it now creates and sets an empty map if the attribute is null. The DefaultLifecycleExecutor was changed to extend my LifecycleExecutor extension and implement the executeSuperInit() method. The executeSuperInit() method creates a single goal, super-init, and then executes it. A element with the id, super-init and a single phase also named super-init was added to the components.xml. The phase has no plugin bindings. Finally the DefaultMaven class has picked up a method to check if any projects in the reactor has plugin execution bindings to the super-init phase. If so then the LifecycleExecutor is called to execute the super-init phase and then if there are no errors the reactor's projects are resorted and normal reactor processing kicks in. This is all 100% backwards compatible because unless you bind a plugin to the phase then the extra processing won't happen and it will be business as usual. Right now this is working great, but is it a direction maven intends to support? Wb
Re: Maven central reporting API
jallen <[EMAIL PROTECTED]> writes: Hi John, > I'm afraid I not replying to answer your questions but I am very excited > that someone is taking this on! Encouraging posts are always welcomed :-) > > What I have found from promoting a low-cost (read open-source or cheap such > as JIRA/Confluence) ALM environment based upon Maven and Eclipse (as the > integration backbones) is that it's Mavens ability to construct a complete > project portal, snapshotted from the current source base, that has senior > management, CMMi experts and a industry luminaries alike (no names but we're > talking gang-of-four level) all 'ooh-ing' in their seats. I had exactly te same experience with maven the first time I (with other people from my company) produced our first project's sites. > > Information sharing, collaboration and, critically, governance reporting and > enforcement (be it tests reports, quality metrics, heuristics, plan My first motivation was in assessing reliability and quality metrics. > > The development of a proper maven/apache framework to supports > report/measure execution, storage, aggregation, distribution, querying, > publication and of course site integration would result in Maven being > elevated to the place it always set out to be, project comprehension and > technical management, and really enable IT organisations to bridge the gap > between the technical disciplines (code, docs, tests) and the > managerial/governance disciplines (quality, progress, process). As someone > who spends his time researching s/w development methods, processes and tools > strategies for a 1+ billion dollar IT company I know this is what we need > and I think Maven is the perfect platform for it. As you can see, I made some concrete proposals to reach this goal and am currently trying to implement some kind of proof of concept that would. But maven is a huge underdocumented beast to tame, even with the kind support of the list. I am currently trying to create a centralized RDF database using a plugin (ie. not touching on maven core) but I have basic problems to extract informations from my plugin's environment. Progress will be slow but there seems to be more than one people interested in it so I am eager to show something that could form the basis of a maven component. > > soapbox-eof Not sure of translation. Is this the same as "brosse à reluire" in french ? regards, -- OQube < software engineering \ génie logiciel > Arnaud Bailly, Dr. \web> http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Mojo testing framework
Hi, I am trying to write a complete test suite for the EAR plugin and I am wondering if there is a documentation somewhere about available tools / techniques. My needs are the following: - Ability to define test projects with the ability to execute the mojo and assert results - Dependencies management with a fake local repository (see eclipse plugin tests for instance) I have checked maven testing harness plugin but it seems that the MavenProject mock object does not resolve dependencies automatically. Am I missing something? Thanks, Stéphane -- .::You're welcome ::. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [RANT] Maven is both heaven and hell
(Since you didn't mention it) CruiseControl works really well for us, if you need something now. -Original Message- From: Wendell Beckwith [mailto:[EMAIL PROTECTED] Sent: Monday, September 04, 2006 11:41 AM To: Maven Developers List Subject: Re: [RANT] Maven is both heaven and hell [snip] > >> > 2.) Produce nightly and weekly integration builds. > >> > >> We already do. We could do it better. I've brought this topic up a > >> couple of times on the Continuum list. > > > > > > I'm not on that list but I guess I will have to be to get a better > > picture of what's going on. > > I expect this to become much more prevalent soon as Continuum is > getting the features we need to support it. Yes, I understand . We're watching Continuum's development too because we would like to use it once it's feature set is improved. We currently have Anthill Pro, but http://www.zutubi.com/ Pulse looks to be a good contender also since I only care about subv repos now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven central reporting API
Hi Arnaud, > To delve deeper into this, I am having a hard time finding maven's big > picture and unfortunately, > comments in code are rather fragmentary and barely useful (when they > exist). Is there a document on maven architecture somewhere ? Think > the answer is no, but asking anyway :-) First of all, I just want to say that I am (and probably a lot of others too) very happy to see some actual work being done on aggregation of reports :) About documentation on Maven Architecture, we had this discussion at work today and most of the documentation are "Howtos" or "Guides". Document on Maven Architecture, concepts etc would be very useful. Basically, to get an idea how things work, how they play together and so on. If you do find something please post a link to it in this thread. Kind regards, Jimisola -- View this message in context: http://www.nabble.com/Maven-central-reporting-API-tf2195661.html#a6139033 Sent from the Maven Developers forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Anyway to call a goal from a mojo?
Code samples are always nice :-) I did also run into '@execute goal=install' which appears to invoke the 'install' goal of my plugin before the goal will execute. This might work for my needs, though I'm not sure exactly how the execution configuration relates to mojo's invoked in this manner. Is this "feature" documented somewhere? --jason On Sep 3, 2006, at 8:47 PM, Rahul Thakur wrote: You can use MavenEmbedder to do this. Pretty sure there was some example code floating on the user@ or dev@ list. I wrote a delegate mojo a while ago that does something similar but don't have the code handy here, but I can dig later today if you are keen at looking at it. Cheers, Rahul Jason Dillon wrote: Is there any (easy) way to call a goal from a mojo? I've got a geronimo:install goal, that does some assembly unpacking, and a geronimo:start goal which starts up the server. geronimo:start really needs to call geronimo:install before it runs. Is there an easy way to do this? The only way I can think to share this code, is to add more abstract classes to hold the methods... but that gets messy fast. Any ideas? --jason - 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: [RANT] Maven is both heaven and hell
On 9/4/06, Brett Porter <[EMAIL PROTECTED]> wrote: On 30/08/2006, at 6:10 AM, Wendell Beckwith wrote: > For my team, I have been using, with minor adaptations, the eclipse > dev > process and in general I think it has the right amount of > "agility". We > post our plan early with our commited, proposed, deferred and > rejected items > for the next release and we revise it through out the release > process. We > use confluence for posting so that people interested in it can > subscribe > just to that page to cut down on unwanted emails. Therefore, when > we make > updated everyone who wants to be notified is notified and they can > either > comment on the issues we have attached to each plan item or start a > forum > discussion. I've create a template that maybe of use to you all if > you > wanted to go this way. We use the JIRA roadmap. I'd be surprised if this is far different from what you are doing, with the exception that: - we are currently stalled. There is no trunk activity because our focus is elsewhere (if anyone has time to pick things up and run with them, great! No need to wait for the rest of us :) - we only really start putting dates to things once there is some momentum, and that's when the feature cull happens and it gets constantly reviewed to try and get things happening regularly. But I'm not adverse to having more visible documentation of what we have to do and when we think we might be able to do it. It will help getting people focused on things, and introduce a way in for contributors. We use Jira too. It's actually because I use Jira from so many open source projects that I introduced Jira into my own company and it caught on like wildfire. That's a surprising admission sense I never would have thought of maven development as being stalled. Thank goodness Google gives me a couple gigs for email otherwise I would have to dump email every other day it seems. I just looked at the roadmap and there are 578 issues combined between maven 2.0.5 and 2.1, approx. 41.2 issues per listed dev assignee. For 2 releases that's not an insane #. So from your standpoint we should just checkout the trunk and go to town submitting patches? >> >> > 2.) Produce nightly and weekly integration builds. >> >> We already do. We could do it better. I've brought this topic up a >> couple of times on the Continuum list. > > > I'm not on that list but I guess I will have to be to get a better > picture > of what's going on. I expect this to become much more prevalent soon as Continuum is getting the features we need to support it. Yes, I understand . We're watching Continuum's development too because we would like to use it once it's feature set is improved. We currently have Anthill Pro, but http://www.zutubi.com/ Pulse looks to be a good contender also since I only care about subv repos now. >> I'm happy to guide you into any area where you are interested to help >> out. So, is it documentation that you want to help with? We have a >> list of outstanding tasks which I can put in one place. >> >> Or would you like to help pull together the roadmap for external >> consumption? > > > I'm open to working with either or both. I do believe that > production of > the roadmap can help guide how to prioritize what documentation > will be > needed and when though. Ok, how can we help get you started? I was really spinning my wheels last week, but I've gotten past that now and opened the Jira issues. However, if I just blow off the docs now, then I'm repeating history. So, I'll start submitting patches for issues that are all ready in Jira. It can help me get better acclimated to how you all function. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven central reporting API
Arnaud Bailly-3 wrote: > > Hi, > A couple of weeks ago I posted a proposal about a centralized > reporting feature for maven that would allow easy aggregation of > information at whatever level is needed. This proposal is centered > around the idea of creating and maintaining a RDF database that could > be used by plugins to find information or store information to be > latter processed by other plugins or external tools. > > I am trying to implement a small proof of concept without modifying > maven base codebase and using only plugins. I plan to do the > following: > 1. a base plugin to create initially the RDF database and populate it > with basic pom's information > 2. a modified compiler plugin to store source files structure > information > 3. a modified surefire plugin to store test results in the graph > attached to the test source files and projects > 4. a modified test report lpugin that would take advantage of the RDF > graph to generate aggregated reports > Hi Arnaud, I'm afraid I not replying to answer your questions but I am very excited that someone is taking this on! I've always felt that the Maven reporting system is one of its most underleveraged features. For me the killer feature list reads: dependency management, reporting, build lifecycle, plugin architecture and POM. What I have found from promoting a low-cost (read open-source or cheap such as JIRA/Confluence) ALM environment based upon Maven and Eclipse (as the integration backbones) is that it's Mavens ability to construct a complete project portal, snapshotted from the current source base, that has senior management, CMMi experts and a industry luminaries alike (no names but we're talking gang-of-four level) all 'ooh-ing' in their seats. Information sharing, collaboration and, critically, governance reporting and enforcement (be it tests reports, quality metrics, heuristics, plan adherence, etc) are seen as essential if an organisation is to properly manage its distributed and sub-contracted software development projects (read: without there being an overworked technical lead/architect burning midnight oil trawling through artefact repositories, running bespoke tools, updating spreadsheets and generating management reports:)) I would like to suggest to the maven core team, and i feel cheaky saying this as i know how busy they are and how hard they work (deseve a medal I tell you, or at the least an IPO!) is that they properly invest in the reporting side of things. Currently the reporting plugins don't have the same support that build plugins have in terms of standard Maven features (e.g. plugin configuration, dependency managemnt) and many aspects of the reporting environment are just not as well developed or thought out as other areas of Maven are (e.g. hardcoded project-info reports, difficulties integrating bespoke reports/pages into the site environment, lack of a framework to support project measures, etc). The development of a proper maven/apache framework to supports report/measure execution, storage, aggregation, distribution, querying, publication and of course site integration would result in Maven being elevated to the place it always set out to be, project comprehension and technical management, and really enable IT organisations to bridge the gap between the technical disciplines (code, docs, tests) and the managerial/governance disciplines (quality, progress, process). As someone who spends his time researching s/w development methods, processes and tools strategies for a 1+ billion dollar IT company I know this is what we need and I think Maven is the perfect platform for it. soapbox-eof John Allen -- View this message in context: http://www.nabble.com/Maven-central-reporting-API-tf2195661.html#a6137872 Sent from the Maven Developers forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven central reporting API
Brett Porter <[EMAIL PROTECTED]> writes: >> 2. How can I retrieve a mojo instance from another mojo in the same >> or a sub project ? > > I think the answer is that you can't. All plugin communication is > meant to happen through the project instance. > > We certainly need to find a way to make that extensible, but I'd > suggest for now that you should be taking in XML output files that > most plugins generate and processing them for starters. > That's really annoying if I want to handle aggregation properly (and this is the whole point of what I am trying to do :-) ) What I really need is way to climb back in the project's tree to retrieve some configuration value of a mojo. For instance, I may have the following config: root project (database: foo.rdf) | + project A (agg: yes, database: FooA.rdf) | +- subbproject A1 +- subbproject A2 | + project B (agg: no) +- subbproject B1 +- subbproject B2 When I am executing mojo for project B2, I want to retrieve RDF database for root. But in A1, I need database FooA. I maybe could do it using the MavenProject object but I could not share database instance and that will lead to really messy code I think. > I have seen some people think about it from time to time, but not in > any detail. Definitely worth investigating, particularly as a way of > reviewing how we handle the lifecycle concurrency issues. To delve deeper into this, I am having a hard time finding maven's big picture and unfortunately, comments in code are rather fragmentary and barely useful (when they exist). Is there a document on maven architecture somewhere ? Think the answer is no, but asking anyway :-) Thx for your reply, -- OQube < software engineering \ génie logiciel > Arnaud Bailly, Dr. \web> http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RANT] Maven is both heaven and hell
Yes, there are some open tasks (That I forwarded to the dev list last week) to start stitching things together. Once this is done we should do a big push of all the plugin documentation. Any fixes that are made now should go on the plugin trunk - there's no other place for it, the stuff on the website is just what it was at for the last release. - Brett On 30/08/2006, at 11:46 AM, Franz Allan Valencia See wrote: Good day, About a couple of months ago, the documentation site of the maven 2 plugins have been revised [1]. Though most have already been reviewed, they are still not yet out for release. However, now that the documentation issue have been raised again, I am wondering of how we are going to go about this? Are new documentation issues be applied to (a) the current documentation in the maven site, (b) the latest documentation though they're not yet released, (c) both a & b, or (d) ? Thanks, Franz [1] http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Documentation - 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: [RANT] Maven is both heaven and hell
On 30/08/2006, at 6:10 AM, Wendell Beckwith wrote: For my team, I have been using, with minor adaptations, the eclipse dev process and in general I think it has the right amount of "agility". We post our plan early with our commited, proposed, deferred and rejected items for the next release and we revise it through out the release process. We use confluence for posting so that people interested in it can subscribe just to that page to cut down on unwanted emails. Therefore, when we make updated everyone who wants to be notified is notified and they can either comment on the issues we have attached to each plan item or start a forum discussion. I've create a template that maybe of use to you all if you wanted to go this way. We use the JIRA roadmap. I'd be surprised if this is far different from what you are doing, with the exception that: - we are currently stalled. There is no trunk activity because our focus is elsewhere (if anyone has time to pick things up and run with them, great! No need to wait for the rest of us :) - we only really start putting dates to things once there is some momentum, and that's when the feature cull happens and it gets constantly reviewed to try and get things happening regularly. But I'm not adverse to having more visible documentation of what we have to do and when we think we might be able to do it. It will help getting people focused on things, and introduce a way in for contributors. > 2.) Produce nightly and weekly integration builds. We already do. We could do it better. I've brought this topic up a couple of times on the Continuum list. I'm not on that list but I guess I will have to be to get a better picture of what's going on. I expect this to become much more prevalent soon as Continuum is getting the features we need to support it. I'm happy to guide you into any area where you are interested to help out. So, is it documentation that you want to help with? We have a list of outstanding tasks which I can put in one place. Or would you like to help pull together the roadmap for external consumption? I'm open to working with either or both. I do believe that production of the roadmap can help guide how to prioritize what documentation will be needed and when though. Ok, how can we help get you started? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven central reporting API
On 31/08/2006, at 7:44 PM, Arnaud Bailly wrote: Questions (which may be trivial) are: 1. Is there one mojo instance for each project in the hierarchy ? I think this is the case but I am not sure. The mojo is instantiated every time it is run (so yes, per project, but also per execution per project). 2. How can I retrieve a mojo instance from another mojo in the same or a sub project ? I think the answer is that you can't. All plugin communication is meant to happen through the project instance. We certainly need to find a way to make that extensible, but I'd suggest for now that you should be taking in XML output files that most plugins generate and processing them for starters. The various POM's ingredients describes either: 1. data *values*, to be later processed by *functions*: File path settings, configuration options, project's id card all fall into this case. These values are organized in a tree such that one can refer to variable's values using dotted notation (eg. =foo.bar.baz=) 2. *functions* that process the project's data, that is essentially plugins (essentiallye mojos), which may themselves be parameterized by some more data or values. Yes, I identified this mix as an issue some time back and we've only really half talked about it and how it will be addressed. If we get some momentum on 2.1 design tasks at any point I'll certainly push it forward again (you can see that in the archives by searching for POM inheritance). Thinking that way, one can imagine doing the following things: - provide a non-XML language layer tha would allow expressing a build process in an easier to use form than what is actually available - compile the build program for: - optimizing the build time - eventually detecting concurrency pattern such that distributed execution (eg. using compile farms) coul be provided Is this plain scrap or has someone else already thought about doing that kind of things ? I have seen some people think about it from time to time, but not in any detail. Definitely worth investigating, particularly as a way of reviewing how we handle the lifecycle concurrency issues. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: rbac role/operation/permission example allocation
heres my thoughts, point form: 1) You can remove the index roles for a repo maintainer, since the index is global to the installation. 2) I'd rename "generate checksums" to regenerate or fix (probably fix) 3) what's toggle service? 4) what's download|add-metadata? Why is it different from the artifact? I'm thinking this might be more of an "edit POM" role, which I'd call just that. The rest sounds fine to me On 02/09/2006, at 12:29 PM, Jesse McConnell wrote: Archiva Administration Roles: Administrator * add-index * regenerate-index * remove-index * modify-index * toggle-service Repository Roles (per repo): Repository Observer * view-reports Repository Maintainer * Repository Observer + * generate-reports * add-index * remove-index * modify-index * regenerate-index * generate-checksums Project Roles (per project): Project Observer * download-artifact * download-metadata Project Maintainer * Project Observer + * add-artifact * add-metadata * remove-artifact * remove-metadata * modify-artifact * modify-metadata * generate-checksums Operations: add-index regenerate-index remove-index modify-index toggle-service [turn off service to the site for maintaince, etc] view-reports generate-reports add-artifact remove-artifact modify-artifact download-artifact add-metadata remove-metadata modify-metadata download-metadata generate-checksums REPOSITORY/PROJECTS: RBAC does permission checks based on an object that a particular operation is trying to be invoked for or on. To maintain obtain common object that is fine grained enough for use with archiva the idea is to use a tuple of repository and project to describe a particular object that an operation is being associated with. Note, the binding of an operation and an object is a permission and that permission is in turn associated with one or more roles. The use of a wildcard or keyword can be used to denote that a particular operation applies to all items that match the wildcard pattern. The notation for a permission is P(OPERATION, OBJECT). For example: P( download-artifact, *-jpox ); This permission would grant the role the ability to download jpox artifacts from all repositories being managed. P( generate-checksum, central-* ); This permission would grant the role the ability to generate checksums for all projects in the repository known as central. P( generate-checksums, central-org.maven.apache.* ); This permission would grant the role the ability to generate checksums for all projects with a group id of at least org.maven.apache on the central repository. RBAC Administration: While it is certainly possible to dynamically generate roles and assoicate those roles with permissions it is probably best at this point to attempt to work out a feasible list of jobs and link up the permissions appropriately. We can easily generate the project maintainer and project obverser roles automatically on the creation of a given project and the same goes for linking up another repository. It is simply a matter of knowing what the permission assignments are configured like for a given role and replicating the role as needed and tweaking the name accordingly. When the time comes to dynamically modify permissions and roles the interface can be made quite simple, for example with the assigning of the generate-checksums operation it could be two drop down boxes, the first containing [central, snapshots, all] and the second containing the projects [org, org.apache, org.apache.maven, jpox, jdo, junit, all] Ultimately the point is that with RBAC great care is taken in working out structure of roles, permissions, and operations. The objects part of the puzzle is largely up the implementation and user of the system. -- jesse mcconnell [EMAIL PROTECTED]
Re: Release of maven-changes-plugin
On 4 Sep 06, at 12:52 AM 4 Sep 06, Jochen Wiedmann wrote: Hi, about two months ago, a vote was held for releasing the maven- changes-plugin. (See http://marc.theaimsgroup.com/?t=11538500061&r=1&w=2 Some issues were raised, in particular concerning the maven- changelog-plugin (as opposed to the maven-changes-plugin) and the conclusion was to defer the release. Currently, a single issue is open (MCHANGES-50), which I was never able to reproduce and which shouldn't be called a blocker anyways, at least IMO. My question is, whether it wouldn't be possible to release the thing finally? If it helps, I'd be glad to do the required work. You now have access to: http://svn.apache.org/repos/asf/maven/sandbox/plugins/ So you can cp over the changes plugin and work away. Let me know if you need anything else. Jason. Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release of maven-changes-plugin
On 4 Sep 06, at 12:52 AM 4 Sep 06, Jochen Wiedmann wrote: Hi, about two months ago, a vote was held for releasing the maven- changes-plugin. (See http://marc.theaimsgroup.com/?t=11538500061&r=1&w=2 Some issues were raised, in particular concerning the maven- changelog-plugin (as opposed to the maven-changes-plugin) and the conclusion was to defer the release. Currently, a single issue is open (MCHANGES-50), which I was never able to reproduce and which shouldn't be called a blocker anyways, at least IMO. My question is, whether it wouldn't be possible to release the thing finally? If it helps, I'd be glad to do the required work. Great, I think everyone agreed to the creation of the sandbox for Apache committers, so if you give me a few minutes and maybe jump on IRC I will set the sandbox up and can copy the plugin over from trunk and do the work which would, again, be greatly appreciated. Jason. Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Release of maven-changes-plugin
Hi, about two months ago, a vote was held for releasing the maven-changes-plugin. (See http://marc.theaimsgroup.com/?t=11538500061&r=1&w=2 Some issues were raised, in particular concerning the maven-changelog-plugin (as opposed to the maven-changes-plugin) and the conclusion was to defer the release. Currently, a single issue is open (MCHANGES-50), which I was never able to reproduce and which shouldn't be called a blocker anyways, at least IMO. My question is, whether it wouldn't be possible to release the thing finally? If it helps, I'd be glad to do the required work. Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Latest surefire plugin failure
It's fixed now. surefire-api snapshot wasn't deployed. Emmanuel Brett Porter a écrit : -- Forwarded message -- From: Martin Gilday <[EMAIL PROTECTED]> Date: 04-Sep-2006 21:57 Subject: Latest surefire plugin failure To: users@maven.apache.org I have just fired up maven to run some tests today and it triggered a large downloading of updated plugins. I am now getting a null pointer exception from surefire. java.lang.NoClassDefFoundError: org/apache/maven/surefire/util/UrlUtils at org.apache.maven.surefire.booter.SurefireBooter.createClassLoader(SurefireBooter.java:599) at org.apache.maven.surefire.booter.SurefireBooter.getTestClassLoader(SurefireBooter.java:569) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:250) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:807) Is this a known issue? - 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]
Fwd: Latest surefire plugin failure
-- Forwarded message -- From: Martin Gilday <[EMAIL PROTECTED]> Date: 04-Sep-2006 21:57 Subject: Latest surefire plugin failure To: users@maven.apache.org I have just fired up maven to run some tests today and it triggered a large downloading of updated plugins. I am now getting a null pointer exception from surefire. java.lang.NoClassDefFoundError: org/apache/maven/surefire/util/UrlUtils at org.apache.maven.surefire.booter.SurefireBooter.createClassLoader(SurefireBooter.java:599) at org.apache.maven.surefire.booter.SurefireBooter.getTestClassLoader(SurefireBooter.java:569) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:250) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:807) Is this a known issue? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Apache Maven - http://maven.apache.org "Better Builds with Maven" book - http://library.mergere.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Seeking help to understand maven-artifact-manager snapshot handling
On 04/09/2006, at 8:47 PM, Max Bowsher wrote: What is the canonical description of the difference between baseVersion and version? baseVersion = 1.0-SNAPSHOT. version = 1.0-20060809.141516-1 (under uniqueVersion) or 1.0-SNAPSHOT (non-uniqueVersion, or locally installed). Similarly, for non-snapshots, baseVersion = version. Does this code chunk ever get used in cases other than when baseVersion contains "SNAPSHOT" and version contains a timestamped version? No, because this sentence is exactly the first line of code written in English :) Is there a good reason for setting the artifact's file to the baseVersion generated name, instead of the version generated name? What is the purpose of making the copy - couldn't everything use the name of the file already existing? To be honest, I can't remember and would need to look more closely at the code whether it is required. Is it deliberate that at the end of this block, the artifact's baseVersion has been set to its version? I think that's a bug, I've seen directories with the timestamp turn up in the local repository and was wondering where that came from. Thanks in advance to anyone who has the patience to answer - I realize that's a rather large list of questions. -- Max Bowsher <[EMAIL PROTECTED]> http://www.mxtelecom.com - 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]
Seeking help to understand maven-artifact-manager snapshot handling
Hi, Attempting to debug MJAR-28 has led me to a section of code in: org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve which I would like to ask for some help understanding why it does what it does. Here is the code chunk in question: if ( artifact.isSnapshot() && !artifact.getBaseVersion().equals( artifact.getVersion() ) ) { String version = artifact.getVersion(); artifact.selectVersion( artifact.getBaseVersion() ); File copy = new File( localRepository.getBasedir(), localRepository.pathOf( artifact ) ); if ( resolved || !copy.exists() ) { // recopy file if it was reresolved, or doesn't exist. try { FileUtils.copyFile( destination, copy ); } catch ( IOException e ) { throw new ArtifactResolutionException( "Unable to copy resolved artifact for local use: " + e.getMessage(), artifact, remoteRepositories, e ); } } artifact.setFile( copy ); artifact.selectVersion( version ); } My questions are: What is the canonical description of the difference between baseVersion and version? Does this code chunk ever get used in cases other than when baseVersion contains "SNAPSHOT" and version contains a timestamped version? Is there a good reason for setting the artifact's file to the baseVersion generated name, instead of the version generated name? What is the purpose of making the copy - couldn't everything use the name of the file already existing? Is it deliberate that at the end of this block, the artifact's baseVersion has been set to its version? Thanks in advance to anyone who has the patience to answer - I realize that's a rather large list of questions. -- Max Bowsher <[EMAIL PROTECTED]> http://www.mxtelecom.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: http://jira.codehaus.org/browse/SUREFIRE-53
Can you give some more details? There are 2 classloaders created - one for surefire itself, containing surefire code and the testing framework; the second one contains only the test dependencies from the POM. If your annotations can't be found, they're missing from the project test path. Or the two classloaders described above aren't linked. If it worked before, it shouldn't have, because the root classloader shouldn't contain the testng annotations. Could you provide a unit test? -- Kenney Jesse Kuhnert wrote: Applying the patch mentioned has made running annotation based testng tests b0rken. Ie before it was loading classes using a context of system class loader. I've fixed this locally by calling createClassLoader(classpathurls, childdelegation, true) (which uses system class loader by default) instead of createClassLoader(classpathurls, null, childdelegation, true). The recent application of old patches is definitely appreciated, but things like this make me nervous for the future. There ~has~ to be a reasonable way to run unit tests against surefire that assert things aren't broken...The logic of classloader dependencies is too fragile to not have tests... Sorry, I shouldn't be telling you guys what to do.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using plexus to inject custom objects (and inject their parameters)?
On 3 Sep 06, at 9:46 PM 3 Sep 06, Jason Dillon wrote: Thanks, but I can wait until this is rolled up into a release. I think having this will really make it easier to create more powerful mojos... and to share commonly used configuration and logic objects w/o needing to sub-class. Yes, it would be generally useful for plexus components in general. --jason On Sep 3, 2006, at 6:12 PM, Jason van Zyl wrote: On 3 Sep 06, at 8:57 PM 3 Sep 06, Jason Dillon wrote: Hi, I asked about this in #maven a while ago, but I forgot what the answer was. How can I configure plexus to inject custom objects into my mojo, and have plexus inject parameters into that object? For example, say I have: public class ConntectionConfig { /** * The port number to connect to the server.. * * @parameter expression="${port}" default-value="1099" */ public int port = -1; /** * The username to authenticate with. * * @parameter expression="${username}" default-value="system" */ public String username = null; /** * The password to authenticate with. * * @parameter expression="${password}" default-value="manager" */ public String password = null; } And a mojo like: /** * @goal test */ public class TestMojo extends ... { /** * Connection configuration * * @parameter */ protected ConntectionConfig connection = null; } I'd like to be able to: mvn whatever:test -Dusername=foo Which will create a new ConnectionConfig, inject username from $ {username} and then initialize the other fields to to their default-values. I tried briefly, using @plexus.component for ConnectionConfig, and then @component for the connection parameter... but it did not inject anything into the ConnectionConfig object. If I specify something like: foo Then username does get set to foo, but the others are left as nulls. I really need a better way to share configuration and logic among mojo's... inheritance is not cutting it, as some mojos end up with more than they really need, and I'm forced to create a bunch of intermediate abstract classes to organize which mojos need what. Is this possible? And if so, can someone point me at a simple example? The configuration model for a mojo is not inspected for annotations what what you have above for the ConnectionConfig is not going to processed. I've added: http://jira.codehaus.org/browse/PLX-266 As this would be generally useful. There are some issues related to the component descriptor creator (CDC) for default configuration values as well. So, short answer right now with 2.0.4 it's not possible. If you're using trunk and you're desperate I can do something. Thanks, --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [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] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]