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:
snip
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;
}
/snip
And a mojo like:
snip
/**
* @goal test
*/
public class TestMojo
extends ...
{
/**
* Connection configuration
*
* @parameter
*/
protected ConntectionConfig connection = null;
}
/snip
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:
configuration
connection
usernamefoo/username
/connection
/configuration
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]
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: 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]
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: 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]
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=11538500061r=1w=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: 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=11538500061r=1w=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]
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=11538500061r=1w=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: 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: 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: [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
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: 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: [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: 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: 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: [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]
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: 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]
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 lifecycle 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: 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]
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=11538500061r=1w=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: 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=revrev=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=diffrev=440170r1=440169r2=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 @@ dependency groupIdeasymock/groupId artifactIdeasymock/artifactId + version1.2_Java1.3/version /dependency /dependencies build - 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 lifecycle 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: 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=439352r1=439351r2=439352view=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 @@ groupIdorg.apache.maven.wagon/groupId artifactIdwagon-provider-api/artifactId /dependency +dependency + groupIdeasymock/groupId + artifactIdeasymock/artifactId +/dependency /dependencies /project 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)
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: 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: [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: 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 dev@maven.apache.org 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]
