Re: [vote] Paul Gier as Maven committer
+1 Vincent 2008/2/28, John Casey <[EMAIL PROTECTED]>: > I'd like to propose giving commit access to Paul Gier. > > He's been instrumental in the recent push to release the assembly > plugin, and I see his work (debugging some issues, patches for other > issues) all over JIRA. Not to mention he's pretty active on IRC, and > he's helping people out on the users list as well. > > IMO, we need more people as involved as Paul has been, to keep Maven > humming along. > > Please vote. 72h +1/+0/-1 > > Here's my +1. > > -john > > --- > > John Casey > Committer and PMC Member, Apache Maven > mail: jdcasey at commonjava dot org > blog: http://www.ejlife.net/blogs/john > rss: http://feeds.feedburner.com/ejlife/john > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wagon changes and WebDAV
On 01/03/2008, at 11:30 AM, Jason van Zyl wrote: Yes, I'm generally in favour of the proposal - it is how we've always wanted it to work. I'm just chucking out ideas. Yep, I just meant in reference to not needing to distribute stuff in the core. - I don't see any point of putting the deploy plugin version in there - the standard mechanism is fine. It may not be the deploy plugin if it became a core version component, but what do you mean by the standard mechanism? In > and or do you mean the auto version selection? Yeah, I think it's worth continuing to use the deploy plugin and specifying it in the section (along with version and configuration), but maybe scoping it back to the alternate deployment scenarios (like altDeploymentRepository, deploy-file), and pushing more of the standard configuration into distributionManagement like you indicated (And that functionality into the core component if relevant). Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wagon changes and WebDAV
On 29-Feb-08, at 3:40 PM, Brett Porter wrote: On 01/03/2008, at 9:02 AM, Jason van Zyl wrote: Here's the direction I would like to go in: http://docs.codehaus.org/display/MAVEN/URL-based+dynamic+loading+of+providers+for+artifact+retrieval+and+deployment Full support for all types of transport for retrieval and deployment in a standard way that doesn't bloat out the core. Yes, I'm generally in favour of the proposal - it is how we've always wanted it to work. I'm just chucking out ideas. Comments on the proposal: - I don't see anything that allows strictly versioning the providers. This may not be a concern as I don't know if that really impacts reproducibility of the build, but there does need to be a way to pin it down. How about an optional element in the deployment target (currently under distMgmt): org.apache.maven.wagon wagon-ssh-external 1.0 - +1 to move selected configuration into the distMgmt. However, anything that might be overridden on a case-by-case basis (like altDeploymentRepository) should not be in there - I don't see any point of putting the deploy plugin version in there - the standard mechanism is fine. It may not be the deploy plugin if it became a core version component, but what do you mean by the standard mechanism? In and or do you mean the auto version selection? Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Maven Assembly Plugin 2.2-beta-2 Released --> Ref #[1MFnp02kuP0MEmu]
Unsubscribed [EMAIL PROTECTED] On 01/03/2008, at 11:10 AM, Arnaud HERITIER wrote: Can we unsubcribe it ??? Arnaud -- Forwarded message -- From: <[EMAIL PROTECTED]> Date: 1 Mar 2008 00:06:57 - Subject: Re: [ANN] Maven Assembly Plugin 2.2-beta-2 Released --> Ref #[1MFnp02kuP0MEmu] To: [EMAIL PROTECTED] Hello, Thank you for contacting NetZero. This is an automated reply and no further response will be sent. Please do not reply to this email. If you are looking for help here are some useful links: * Online NetZero Help Center: http://www.netzero.com/support * Online Billing and Account Center: https://account.netzero.net * Reset/Retrieve your Password: http://my.netzero.com/s/resetpassword * Lookup Access Numbers in your area: http://my.netzero.com/s/numbers * Contact Us: http://www.netzero.net/support/support.html Thank you for choosing NetZero. Sincerely, NetZero Customer Support - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: [ANN] Maven Assembly Plugin 2.2-beta-2 Released --> Ref #[1MFnp02kuP0MEmu]
Can we unsubcribe it ??? Arnaud -- Forwarded message -- From: <[EMAIL PROTECTED]> Date: 1 Mar 2008 00:06:57 - Subject: Re: [ANN] Maven Assembly Plugin 2.2-beta-2 Released --> Ref #[1MFnp02kuP0MEmu] To: [EMAIL PROTECTED] Hello, Thank you for contacting NetZero. This is an automated reply and no further response will be sent. Please do not reply to this email. If you are looking for help here are some useful links: * Online NetZero Help Center: http://www.netzero.com/support * Online Billing and Account Center: https://account.netzero.net * Reset/Retrieve your Password: http://my.netzero.com/s/resetpassword * Lookup Access Numbers in your area: http://my.netzero.com/s/numbers * Contact Us: http://www.netzero.net/support/support.html Thank you for choosing NetZero. Sincerely, NetZero Customer Support - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ...
Re: Wagon changes and WebDAV
On 01/03/2008, at 9:02 AM, Jason van Zyl wrote: Here's the direction I would like to go in: http://docs.codehaus.org/display/MAVEN/URL-based+dynamic+loading+of+providers+for+artifact+retrieval+and+deployment Full support for all types of transport for retrieval and deployment in a standard way that doesn't bloat out the core. Yes, I'm generally in favour of the proposal - it is how we've always wanted it to work. Comments on the proposal: - I don't see anything that allows strictly versioning the providers. This may not be a concern as I don't know if that really impacts reproducibility of the build, but there does need to be a way to pin it down. How about an optional element in the deployment target (currently under distMgmt): org.apache.maven.wagon wagon-ssh-external 1.0 - +1 to move selected configuration into the distMgmt. However, anything that might be overridden on a case-by-case basis (like altDeploymentRepository) should not be in there - I don't see any point of putting the deploy plugin version in there - the standard mechanism is fine. Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] [vote] Release maven-assembly-plugin 2.2-beta-2 and maven-repository-builder 1.0-alpha-2
binding +1: John Casey, Brett Porter, Jason van Zyl non-binding +1: Sejal Patel, Fabrice Bellingard No other votes. I've released the binaries to the synchronization point on people.apache.org, and will do likewise with the assembly plugin site momentarily. Thanks, everyone! -john --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john
Re: [vote] Release maven-assembly-plugin 2.2-beta-2 and maven-repository-builder 1.0-alpha-2
+1
Works for my assemblies.
On 21-Feb-08, at 11:01 AM, John Casey wrote:
Hi all,
I'd like to propose that we release both the assembly plugin and one
of its shared-component dependencies: maven-repository-builder. See
below for more information on what's included in these releases. I
have two staging repositories for these projects:
maven-assembly-plugin:
http://people.apache.org/~jdcasey/stage/maven-assembly-plugin/2.2-beta-2/
maven-repository-builder:
http://people.apache.org/~jdcasey/stage/maven-repository-builder/1.0-alpha-2/
You can try them out using the following settings.xml snippet:
maven-assembly-plugin.stage
mrb.stage
http://people.apache.org/~jdcasey/stage/maven-repository-builder/1.0-alpha-2
false
map.stage
http://people.apache.org/~jdcasey/stage/maven-assembly-plugin/2.2-beta-2
false
map.stage
http://people.apache.org/~jdcasey/stage/maven-assembly-plugin/2.2-beta-2
false
maven-assembly-plugin.stage
Let the voting begin! +1/+0/-1, 72 hrs.
Thanks,
John
--
The main improvement in the repository builder is inclusion of
parent POMs, and some improvements to snapshot handling (though this
may not be complete yet). I'm attaching the SVN log for more
information about these changes.
As for the assembly plugin, there have been quite a few changes in
the last nine months or so:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126&styleName=Html&version=14027
Release Notes - Maven 2.x Assembly Plugin - Version 2.2-beta-2
** Bug
* [MASSEMBLY-121] - Custom manifest attributres are ignored.
* [MASSEMBLY-129] - BaseDirectory Ignored When Including a
Repository
* [MASSEMBLY-156] - appendAssemblyId cannot be false
* [MASSEMBLY-162] - In a multiproject environment, assembly
takes wrong dependencies
* [MASSEMBLY-163] - In a multiproject environment Assembly
causes many unneded rebuilds
* [MASSEMBLY-178] - filtering doesn't read filter files
* [MASSEMBLY-179] - Assembled jar includes artifact names in path
* [MASSEMBLY-180] - A bug in artifact filtering ( maven-common-
artifact-filters )
* [MASSEMBLY-183] - assembly:attached does not work with filter-
ERROR: Cannot override read-only parameter
* [MASSEMBLY-184] - components are not interpolated - i.e., $
{params} are not substituted
* [MASSEMBLY-188] - manifestEntries are not set in resulting jar
* [MASSEMBLY-189] - plugin not correctly interpolating POM
variables like project.build.directory
* [MASSEMBLY-194] - unnecessary dependency expansion regression
* [MASSEMBLY-195] - unpackOptions ignored
* [MASSEMBLY-197] - 2.2-beta-1 regression, project artifact no
longer included in
* [MASSEMBLY-208] - Assembly plugin does not resolve version
ranges correctly
* [MASSEMBLY-210] - repository does not include the parent pom
* [MASSEMBLY-212] - Assembly Descriptor Schemas (XSD) have wrong
targetNamespace
* [MASSEMBLY-214] - java.lang.NullPointerException: version was
null for junit:junit
* [MASSEMBLY-221] - Filtering doesn't work when a file matches
both a and a
* [MASSEMBLY-222] - 2.2-beta-1 regression in assembly descriptor
interpolation
* [MASSEMBLY-223] - 2-nd element of
: doesn't work
* [MASSEMBLY-225] - Not a v4.0.0 POM
* [MASSEMBLY-226] - Filters as read-only parameter can break the
assembly build of a multi-module project
* [MASSEMBLY-232] - NPE - MASSEMBLY-222 fix broken?
* [MASSEMBLY-233] - Custom ContainerDescriptorHandler
integration tests don't work in Maven 2.0.7
* [MASSEMBLY-234] - Artifacts not deployed
* [MASSEMBLY-235] - dependencySet ignores dependency management
* [MASSEMBLY-250] - Trunk of assembly plugin broken and not in
synch with deployed 2.2-beta2-SNAPSHOT ?
* [MASSEMBLY-254] - Not a v4.0.0 POM Still an Issue
* [MASSEMBLY-256] - Regression: pom properties are no longer
expanded in descriptor.
* [MASSEMBLY-257] - OutOfMemoryError when assembling large
binary file
* [MASSEMBLY-262] - unit fail in trunk on windows (need upgrade
of plexus-utils)
* [MASSEMBLY-266] - Property expansion does not work for $
{project.build.finalName} in descriptor file
* [MASSEMBLY-277] - NullPointerException
* [MASSEMBLY-282] - Fix failing IT no-appendAssemblyId-no-
classifier
** Improvement
* [MASSEMBLY-136] - outputDirectory to support absolute paths
* [MASSEMBLY-142] - Should be able to use artifact version as
variable in
* [MASSEMBLY-152] - Support Ant token
* [MASSEMBLY-154] - FileSet does not support filtering
* [MASSEMBLY-182] - document behavior when two sources selected
for single archived file
* [M
Re: Wagon changes and WebDAV
Here's the direction I would like to go in: http://docs.codehaus.org/display/MAVEN/URL-based+dynamic+loading+of+providers+for+artifact+retrieval+and+deployment Full support for all types of transport for retrieval and deployment in a standard way that doesn't bloat out the core. On 29-Feb-08, at 1:37 PM, Jason van Zyl wrote: The other problem with dropping it into the distribution is that when we find out there is a bug in it you can't simply specify a new version of the provider, you would have to go replace the provider and all its deps, or make your own shaded JAR which would be a pain in the ass. On 29-Feb-08, at 12:22 PM, Brian E. Fox wrote: +1 to putting in on the url, that's a muuuch better solution and works for all wagons, not just webdav. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, February 29, 2008 2:25 PM To: Maven Developers List Subject: Re: Wagon changes and WebDAV On 28-Feb-08, at 9:58 PM, Joakim Erdfelt wrote: Jason van Zyl wrote: On 28-Feb-08, at 1:35 PM, Brett Porter wrote: On 29/02/2008, at 5:51 AM, Jason van Zyl wrote: I'm going to roll back all the WagonDAV changes as 1) As we discussed about extensions on the list that for deployment the required libraries necessary for deployment should be dependencies listed in the deployment plugin and not wired into the core. 2) The wagons can now be picked up with the dynamic collections so that's also not necessary to bind them in there. Is this already in place? The use case is for deploy:deploy-file, so (1) is not an option. Dynamic collections have been there for a while. And why is deploy:deploy-file a concern, and for webdav. This will be the case for all providers. FTP deploy doesn't work out of the box either, should be start adding everything because they need a POM to use deploy file with FTP. Probably not. The other issue is why isn't just plain PUT fine. I don't know how it ever came to be that we pushed WebDAV. Plain PUT does not work if the directory doesn't exist yet. (That's part of the HTTP spec). You need something to create the directory (or "Collection" in WebDAV Terms), this is the MKCOL method. This is so simple to add to something like Jetty, my concern is that the WebDAV implementations are so crappy that I've backed away from it as a viable solution. Try running litmus (http://www.webdav.org/neon/litmus/ ) against any of them and they fail miserably. At least the Java ones, and when I mean terrible I mean 60-70% compliant terrible. Andy and Tamas worked a long time on our to try and make it compliant and in the end I don't think it was worth it. It's also just so horrendously slow. The Java implementations are just not that good. So that's probably the crux of my argument. What is there that's better? A simple addition to the PUT handler in Jetty and you have deployment. At any rate as I will say below we can have a lean core and convenience. While it is true that FTP is also a provider, it should be painfully obvious that all existing repository manager implementations support WebDAV. And it's a favorite deployment technique in corporate environments for the security aspects alone. Sure you could accomplish the same thing with SSH, but how many people do you find asking for deploy:deploy-file with ssh in the users list? In many corporations I've been involved in SSH is fine for many tasks, but not repository management for the rank and file or for the continuous integration server. (Typically due to political and maintenance reasonsnot for technical ones) I will show you that it's not necessary to put it in the core to make it easy for people to deploy things. What will the user always have to provide to deploy? The URL? With the URL we can determine the provider (if we can't we have to fix that), and with the provider we can dynamically download and load whatever is necessary with out hassling the user. It all doesn't need to go into the core. We have clear trend established with the users (in the mailing list and jira) that webdav is a popular choice, and the deploy:deploy- file is painful without it being in core, and also no option to build a custom client with it embedded (classloader yech, yada yada). bringing it in via the command line isn't an option. So we're left with creating a pom just to use deploy:deploy-file with webdav. As described above we have all the information we need to make it easy and not bloat the core. As I said before - that's fine, but it should be working before the first alpha so that there's no regression in functionality. It's never been there so it's not a regression because no one has ever used it or done it. If you need a POM to deploy-file that's fine. We're not going to start pushing in all the providers so people can do this. Pushing it all in the core, sprinkling the logic everywhere we need to handle the JARs especially the httpclient mess of commons-
Re: Wagon changes and WebDAV
The other problem with dropping it into the distribution is that when we find out there is a bug in it you can't simply specify a new version of the provider, you would have to go replace the provider and all its deps, or make your own shaded JAR which would be a pain in the ass. On 29-Feb-08, at 12:22 PM, Brian E. Fox wrote: +1 to putting in on the url, that's a muuuch better solution and works for all wagons, not just webdav. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, February 29, 2008 2:25 PM To: Maven Developers List Subject: Re: Wagon changes and WebDAV On 28-Feb-08, at 9:58 PM, Joakim Erdfelt wrote: Jason van Zyl wrote: On 28-Feb-08, at 1:35 PM, Brett Porter wrote: On 29/02/2008, at 5:51 AM, Jason van Zyl wrote: I'm going to roll back all the WagonDAV changes as 1) As we discussed about extensions on the list that for deployment the required libraries necessary for deployment should be dependencies listed in the deployment plugin and not wired into the core. 2) The wagons can now be picked up with the dynamic collections so that's also not necessary to bind them in there. Is this already in place? The use case is for deploy:deploy-file, so (1) is not an option. Dynamic collections have been there for a while. And why is deploy:deploy-file a concern, and for webdav. This will be the case for all providers. FTP deploy doesn't work out of the box either, should be start adding everything because they need a POM to use deploy file with FTP. Probably not. The other issue is why isn't just plain PUT fine. I don't know how it ever came to be that we pushed WebDAV. Plain PUT does not work if the directory doesn't exist yet. (That's part of the HTTP spec). You need something to create the directory (or "Collection" in WebDAV Terms), this is the MKCOL method. This is so simple to add to something like Jetty, my concern is that the WebDAV implementations are so crappy that I've backed away from it as a viable solution. Try running litmus (http://www.webdav.org/neon/litmus/ ) against any of them and they fail miserably. At least the Java ones, and when I mean terrible I mean 60-70% compliant terrible. Andy and Tamas worked a long time on our to try and make it compliant and in the end I don't think it was worth it. It's also just so horrendously slow. The Java implementations are just not that good. So that's probably the crux of my argument. What is there that's better? A simple addition to the PUT handler in Jetty and you have deployment. At any rate as I will say below we can have a lean core and convenience. While it is true that FTP is also a provider, it should be painfully obvious that all existing repository manager implementations support WebDAV. And it's a favorite deployment technique in corporate environments for the security aspects alone. Sure you could accomplish the same thing with SSH, but how many people do you find asking for deploy:deploy-file with ssh in the users list? In many corporations I've been involved in SSH is fine for many tasks, but not repository management for the rank and file or for the continuous integration server. (Typically due to political and maintenance reasonsnot for technical ones) I will show you that it's not necessary to put it in the core to make it easy for people to deploy things. What will the user always have to provide to deploy? The URL? With the URL we can determine the provider (if we can't we have to fix that), and with the provider we can dynamically download and load whatever is necessary with out hassling the user. It all doesn't need to go into the core. We have clear trend established with the users (in the mailing list and jira) that webdav is a popular choice, and the deploy:deploy- file is painful without it being in core, and also no option to build a custom client with it embedded (classloader yech, yada yada). bringing it in via the command line isn't an option. So we're left with creating a pom just to use deploy:deploy-file with webdav. As described above we have all the information we need to make it easy and not bloat the core. As I said before - that's fine, but it should be working before the first alpha so that there's no regression in functionality. It's never been there so it's not a regression because no one has ever used it or done it. If you need a POM to deploy-file that's fine. We're not going to start pushing in all the providers so people can do this. Pushing it all in the core, sprinkling the logic everywhere we need to handle the JARs especially the httpclient mess of commons-* is not very appealing. The work that brett did for in wagon-http (not the lightweight one) cleans up the commons-* stuff significantly (shading the commons-* tree into the org.apache.maven.wagon.common.* package space). In a local snapshot build with maven 2.0.x using this new wagon-http over the existing wagon-http-lightweight found it only ad
Collections and their ordering
Hi,
I would like to advertize the usage of java.util.LinkedHashMap and
java.util.LinkedHashSet. Unlike their close relatives HashMap and HashSet,
the former two collection classes offer a deterministic iteration order of
their elements by keeping the insertion order.
In general, clients will be happy if code retains the order of elements when
processing collections instead of messing them up. A prominent example from
the Maven Core is the following idiom:
List input = ...;
Map temp = new LinkedHashMap();
for ( Iterator it = input.iterator(); it.hasNext(); )
{
temp.put( , it.next() );
}
List output = new ArrayList( temp.values() );
Using HashMap in those cases would yield indeterministic ordering in the
output collection. If one is dealing with artifacts, this means messing up
the class path.
So please think twice whether HashSet/HashMap are really sufficient or
whether there exists the smallest possibility that some client code might
depend on the proper/deterministic ordering.
Regards,
Benjamin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wagon changes and WebDAV
+1 to putting in on the url, that's a muuuch better solution and works for all wagons, not just webdav. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, February 29, 2008 2:25 PM To: Maven Developers List Subject: Re: Wagon changes and WebDAV On 28-Feb-08, at 9:58 PM, Joakim Erdfelt wrote: > Jason van Zyl wrote: >> >> On 28-Feb-08, at 1:35 PM, Brett Porter wrote: >> >>> >>> On 29/02/2008, at 5:51 AM, Jason van Zyl wrote: >>> I'm going to roll back all the WagonDAV changes as 1) As we discussed about extensions on the list that for deployment the required libraries necessary for deployment should be dependencies listed in the deployment plugin and not wired into the core. 2) The wagons can now be picked up with the dynamic collections so that's also not necessary to bind them in there. >>> >>> Is this already in place? The use case is for deploy:deploy-file, >>> so (1) is not an option. >>> >> >> Dynamic collections have been there for a while. And why is >> deploy:deploy-file a concern, and for webdav. This will be the case >> for all providers. FTP deploy doesn't work out of the box either, >> should be start adding everything because they need a POM to use >> deploy file with FTP. Probably not. >> >> The other issue is why isn't just plain PUT fine. I don't know how >> it ever came to be that we pushed WebDAV. > > Plain PUT does not work if the directory doesn't exist yet. (That's > part of the HTTP spec). > You need something to create the directory (or "Collection" in > WebDAV Terms), this is the MKCOL method. > This is so simple to add to something like Jetty, my concern is that the WebDAV implementations are so crappy that I've backed away from it as a viable solution. Try running litmus (http://www.webdav.org/neon/litmus/ ) against any of them and they fail miserably. At least the Java ones, and when I mean terrible I mean 60-70% compliant terrible. Andy and Tamas worked a long time on our to try and make it compliant and in the end I don't think it was worth it. It's also just so horrendously slow. The Java implementations are just not that good. So that's probably the crux of my argument. What is there that's better? A simple addition to the PUT handler in Jetty and you have deployment. At any rate as I will say below we can have a lean core and convenience. > While it is true that FTP is also a provider, it should be painfully > obvious that all existing repository manager implementations support > WebDAV. And it's a favorite deployment technique in corporate > environments for the security aspects alone. > Sure you could accomplish the same thing with SSH, but how many > people do you find asking for deploy:deploy-file with ssh in the > users list? In many corporations I've been involved in SSH is fine > for many tasks, but not repository management for the rank and file > or for the continuous integration server. (Typically due to > political and maintenance reasonsnot for technical ones) I will show you that it's not necessary to put it in the core to make it easy for people to deploy things. What will the user always have to provide to deploy? The URL? With the URL we can determine the provider (if we can't we have to fix that), and with the provider we can dynamically download and load whatever is necessary with out hassling the user. It all doesn't need to go into the core. > > > We have clear trend established with the users (in the mailing list > and jira) that webdav is a popular choice, and the deploy:deploy- > file is painful without it being in core, and also no option to > build a custom client with it embedded (classloader yech, yada > yada). bringing it in via the command line isn't an option. So > we're left with creating a pom just to use deploy:deploy-file with > webdav. As described above we have all the information we need to make it easy and not bloat the core. > > >> >>> As I said before - that's fine, but it should be working before >>> the first alpha so that there's no regression in functionality. >>> >> >> It's never been there so it's not a regression because no one has >> ever used it or done it. If you need a POM to deploy-file that's >> fine. We're not going to start pushing in all the providers so >> people can do this. Pushing it all in the core, sprinkling the >> logic everywhere we need to handle the JARs especially the >> httpclient mess of commons-* is not very appealing. > > The work that brett did for in wagon-http (not the lightweight one) > cleans up the commons-* stuff significantly (shading the commons-* > tree into the org.apache.maven.wagon.common.* package space). In a > local snapshot build with maven 2.0.x using this new wagon-http over > the existing wagon-http-lightweight found it only added about 300k > to the size of the distro along with making f
Re: [vote] Paul Gier as Maven committer
+1 John Casey wrote: I'd like to propose giving commit access to Paul Gier. He's been instrumental in the recent push to release the assembly plugin, and I see his work (debugging some issues, patches for other issues) all over JIRA. Not to mention he's pretty active on IRC, and he's helping people out on the users list as well. IMO, we need more people as involved as Paul has been, to keep Maven humming along. Please vote. 72h +1/+0/-1 Here's my +1. -john --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE][RESULT] Release maven-parent pom 8 (take 2)
This vote passed with the following votes: +1 Dennis Lundberg, Jason van Zyl, Olivier Lamy, Vincent Siveton No other votes. I will start the release process. Dennis Lundberg wrote: Hi To get the latest version of maven-source-plugin into our toolchain, I'd like to release maven parent pom r630638 as version 8. A site.xml has been added in this release. Source: https://svn.apache.org/viewvc/maven/pom/trunk/maven/pom.xml?r1=587312&r2=630638&diff_format=h https://svn.apache.org/viewvc/maven/pom/trunk/maven/src/site/site.xml?diff_format=h&revision=630311&view=markup SNAPSHOT: A SNAPSHOT has been uploaded as maven-parent 8-20080224.171708-6. The vote will be open for 72 hours. +1 from me -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wagon changes and WebDAV
On 28-Feb-08, at 9:58 PM, Joakim Erdfelt wrote: Jason van Zyl wrote: On 28-Feb-08, at 1:35 PM, Brett Porter wrote: On 29/02/2008, at 5:51 AM, Jason van Zyl wrote: I'm going to roll back all the WagonDAV changes as 1) As we discussed about extensions on the list that for deployment the required libraries necessary for deployment should be dependencies listed in the deployment plugin and not wired into the core. 2) The wagons can now be picked up with the dynamic collections so that's also not necessary to bind them in there. Is this already in place? The use case is for deploy:deploy-file, so (1) is not an option. Dynamic collections have been there for a while. And why is deploy:deploy-file a concern, and for webdav. This will be the case for all providers. FTP deploy doesn't work out of the box either, should be start adding everything because they need a POM to use deploy file with FTP. Probably not. The other issue is why isn't just plain PUT fine. I don't know how it ever came to be that we pushed WebDAV. Plain PUT does not work if the directory doesn't exist yet. (That's part of the HTTP spec). You need something to create the directory (or "Collection" in WebDAV Terms), this is the MKCOL method. This is so simple to add to something like Jetty, my concern is that the WebDAV implementations are so crappy that I've backed away from it as a viable solution. Try running litmus (http://www.webdav.org/neon/litmus/ ) against any of them and they fail miserably. At least the Java ones, and when I mean terrible I mean 60-70% compliant terrible. Andy and Tamas worked a long time on our to try and make it compliant and in the end I don't think it was worth it. It's also just so horrendously slow. The Java implementations are just not that good. So that's probably the crux of my argument. What is there that's better? A simple addition to the PUT handler in Jetty and you have deployment. At any rate as I will say below we can have a lean core and convenience. While it is true that FTP is also a provider, it should be painfully obvious that all existing repository manager implementations support WebDAV. And it's a favorite deployment technique in corporate environments for the security aspects alone. Sure you could accomplish the same thing with SSH, but how many people do you find asking for deploy:deploy-file with ssh in the users list? In many corporations I've been involved in SSH is fine for many tasks, but not repository management for the rank and file or for the continuous integration server. (Typically due to political and maintenance reasonsnot for technical ones) I will show you that it's not necessary to put it in the core to make it easy for people to deploy things. What will the user always have to provide to deploy? The URL? With the URL we can determine the provider (if we can't we have to fix that), and with the provider we can dynamically download and load whatever is necessary with out hassling the user. It all doesn't need to go into the core. We have clear trend established with the users (in the mailing list and jira) that webdav is a popular choice, and the deploy:deploy- file is painful without it being in core, and also no option to build a custom client with it embedded (classloader yech, yada yada). bringing it in via the command line isn't an option. So we're left with creating a pom just to use deploy:deploy-file with webdav. As described above we have all the information we need to make it easy and not bloat the core. As I said before - that's fine, but it should be working before the first alpha so that there's no regression in functionality. It's never been there so it's not a regression because no one has ever used it or done it. If you need a POM to deploy-file that's fine. We're not going to start pushing in all the providers so people can do this. Pushing it all in the core, sprinkling the logic everywhere we need to handle the JARs especially the httpclient mess of commons-* is not very appealing. The work that brett did for in wagon-http (not the lightweight one) cleans up the commons-* stuff significantly (shading the commons-* tree into the org.apache.maven.wagon.common.* package space). In a local snapshot build with maven 2.0.x using this new wagon-http over the existing wagon-http-lightweight found it only added about 300k to the size of the distro along with making for a more friendly http provider when dealing with oddball auths, like the one i'm experiencing now that does not allow for preemptive auth, only challenge / response auth with the returned cookie from the challenge, or being able to use NTLM auth. or even being able to use DIGEST auth. something that the wagon-http-lightweight really does not do effectively. Then there's also the performance work coming out of Don Brown, which utiliz
Re: Wagon changes and WebDAV
On 28-Feb-08, at 4:04 PM, Brett Porter wrote: I'm fine removing whatever you want from core once you can show me the same use case working without it. Not a problem, I'll roll it back and use the dynamic collections. I don't want the core getting bloated out when it's not required. Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: releasing maven-artifact
Correct. On 29-Feb-08, at 3:28 AM, Brett Porter wrote: I assume this is the current trunk and not the CAP branch? On 29/02/2008, at 5:34 PM, Jason van Zyl wrote: John/Mark, You have anything that you want to put in maven-artifact as I'm going to start making alphas. I'll take a look at the one issue scheduled for m-a, let you guys add anything you were working on and then squeeze it out to prepare for a 2.1-alpha-1. Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wagon changes and WebDAV
> > Plain PUT does not work if the directory doesn't exist yet. (That's part > of the HTTP spec). > You need something to create the directory (or "Collection" in WebDAV > Terms), this is the MKCOL method. > > While it is true that FTP is also a provider, it should be painfully > obvious that all existing repository manager implementations support > WebDAV. And it's a favorite deployment technique in corporate > environments for the security aspects alone. > > Sure you could accomplish the same thing with SSH, but how many people > do you find asking for deploy:deploy-file with ssh in the users list? > In many corporations I've been involved in SSH is fine for many tasks, > but not repository management for the rank and file or for the > continuous integration server. (Typically due to political and > maintenance reasonsnot for technical ones) > > We have clear trend established with the users (in the mailing list and > jira) that webdav is a popular choice, and the deploy:deploy-file is > painful without it being in core, and also no option to build a custom > client with it embedded (classloader yech, yada yada). bringing it in > via the command line isn't an option. So we're left with creating a pom > just to use deploy:deploy-file with webdav. It's exaclty the problem we are confroted with at the moment. It's a real pain for us and we are still looking for a solution. It's really difficult to manage a maven 2 repository with corporate policy access. For instance : inhouse - groupId1 (allow read/write for the team project/ read for all) - groupId2 (allow read/write for the team project/ read for all) inhouse.snapshot - groupId1 (allow read/write for the team project/ read for all) - groupId2 (allow read/write for the team project/ read for all) How to do it ? We first try with the scp/sftp protocol but it's not working (cf. http://www.nabble.com/-M2--Pb-Release-and-preserve-timestamps-td13626985s177.html#a13626985 ). We now try with the webdav protocol but it's not working because PUT does not work if the directory doesn't exist yet If you have a solution, it would be fantastic ! Rémy
Re: svn commit: r518309 - /maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java
Definitely revert the aggregator tag. It is an uggly pb for many of us.
Vincent
PS: read also the recent Dan's thread
http://www.nabble.com/%40aggregator-mojo-annotation-td15302246s177.html
2008/2/28, Brian E. Fox <[EMAIL PROTECTED]>:
> I say pull the aggregation out (MJAVADOC-104) and find another way to
> deal with this. It's far too destructive. Thanks Wendy for looking this
> up.
>
>
> -Original Message-
> From: Wendy Smoak [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 28, 2008 10:32 PM
> To: dev@maven.apache.org
> Subject: Re: svn commit: r518309 -
> /maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven
> /plugin/javadoc/AbstractJavadocMojo.java
>
> This change (adding @aggregator) is being pointed to as the cause of
> many problems with version 2.3 of the Javadoc plugin.
>
> See http://jira.codehaus.org/browse/MJAVADOC-137 and related issues.
>
> Should all or part of this be reverted?
>
> --
> Wendy
>
> On Wed, Mar 14, 2007 at 1:28 PM, <[EMAIL PROTECTED]> wrote:
> > Author: carlos
> > Date: Wed Mar 14 13:28:56 2007
> > New Revision: 518309
> >
> > URL: http://svn.apache.org/viewvc?view=rev&rev=518309
> > Log:
> > [MJAVADOC-104] Javadoc of generated sources is not generated when
> aggregate=true
> > Submitted By: Julien Henry
> >
> > Modified:
> >
> maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/
> plugin/javadoc/AbstractJavadocMojo.java
> >
> > Modified:
> maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/
> plugin/javadoc/AbstractJavadocMojo.java
> > URL:
> http://svn.apache.org/viewvc/maven/plugins/trunk/maven-javadoc-plugin/sr
>
> c/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java?vie
>
> w=diff&rev=518309&r1=518308&r2=518309
> >
>
> ==
> > ---
> maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/
> plugin/javadoc/AbstractJavadocMojo.java (original)
> > +++
> maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/
> plugin/javadoc/AbstractJavadocMojo.java Wed Mar 14 13:28:56 2007
> > @@ -9,7 +9,7 @@
> > * "License"); you may not use this file except in compliance
> > * with the License. You may obtain a copy of the License at
> > *
> > - * http://www.apache.org/licenses/LICENSE-2.0
> > + * http://www.apache.org/licenses/LICENSE-2.0
> > *
> > * Unless required by applicable law or agreed to in writing,
> > * software distributed under the License is distributed on an
> > @@ -73,6 +73,7 @@
> > * @author mailto:[EMAIL PROTECTED]">Vincent
> Siveton
> > * @requiresDependencyResolution compile
> > * @execute phase="generate-sources"
> > + * @aggregator
> > */
> > public abstract class AbstractJavadocMojo
> > extends AbstractMojo
> > @@ -1338,6 +1339,12 @@
> > MavenProject project = (MavenProject) i.next();
> >
> > List sourceRoots =
> project.getCompileSourceRoots();
> > +
> > +if ( project.getExecutionProject() != null )
> > +{
> > +sourceRoots.addAll(
> project.getExecutionProject().getCompileSourceRoots() );
> > +}
> > +
> > ArtifactHandler artifactHandler =
> project.getArtifact().getArtifactHandler();
> > if ( "java".equals( artifactHandler.getLanguage()
> ) )
> > {
> > @@ -1956,7 +1963,7 @@
> > * @param repeatKey repeat or not the key in the command line
> > * @param splitValue if true given value will be
> tokenized by comma
> > */
> > -private void addArgIfNotEmpty( List arguments, String key,
> String value,
> > +private void addArgIfNotEmpty( List arguments, String key,
> String value,
> > boolean repeatKey, boolean splitValue )
> > {
> > if ( StringUtils.isNotEmpty( value ) )
> > @@ -1971,11 +1978,11 @@
> > while ( token.hasMoreTokens() )
> > {
> > String current = token.nextToken().trim();
> > -
> > +
> > if ( StringUtils.isNotEmpty( current ) )
> > {
> > arguments.add( current );
> > -
> > +
> > if ( token.hasMoreTokens() && repeatKey )
> > {
> > arguments.add( key );
> > @@ -1987,7 +1994,7 @@
> > }
> > }
> > }
> > -
> > +
> > /**
> > * Convenience method to add an argument to the command
> line
> > * if the the value is not null or empty.
> >
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROT
Re: MNG-3284
Can anyone help answer whether I've missed some subtlety as to why a fix like this wouldn't work (I appreciate the inner workings of maven can be a bit complicated...) ? On Sun, Feb 3, 2008 at 6:10 PM, Nigel Magnay <[EMAIL PROTECTED]> wrote: > The problem is that putting it in pluginManagement doesn't help > because the builds genuinely do want to use different versions, > particularly of internally-developed mojos that change in different > (and sometimes incompatible ways). > > A typical case is a base library uses a fixed, stable release, but > another project has needed further development, so moves to a > snapshot. The projects all build in isolation, but in reactor builds > (build project and all dependencies) they fail seemingly mysteriously > ways, because be base library builds first (and is owned by a separate > team who may be unaware) and lock down the plugin. I've also seen it > with different teams using different versions of things like the > assembly plugin. > > Anyway... > > Is 2.1 going to be the next released M2 version, rather than a 2.0.9? > I thought 2.1 was still pretty unstable? > Would the fix (or something like it) in MNG-3284 work? (if not I'm > prepared to do some more work on it, if someone can point me to where > I need to look...) > > TIA, > Nigel > > > > > On Feb 3, 2008 5:56 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote: > > This is fixed in 2.1, but if you are constantly having this problem, it > > sounds like maybe you need to use pluginManagement in a corp pom to > > resolve this issue. > > > > > > -Original Message- > > From: Nigel Magnay [mailto:[EMAIL PROTECTED] > > Sent: Sunday, February 03, 2008 8:44 AM > > To: dev@maven.apache.org > > Subject: MNG-3284 > > > > Hi. > > > > In our work projects, we're *constantly* being bitten by the 'first > > version of a plugin used wins' problem, which seems variously > > described in particular MNG JIRA items, mine in particular being > > MNG-3284. > > > > I've had a go at fixing it as it didn't seem that complicated - but - > > some of the comments in the code and some of the other JIRA tickets > > allude to the problem being possibly bigger than what I've looked at. > > Unfortunately I can't tell if these are things that are still issues > > as it dates back quite a long way. > > > > I'd really like it if someone who's more intimate with the workings > > could tell me what else would need considering - that way I could > > generate some test cases and perhaps have a stab at a wider fix. > > > > TIA, > > Nigel > > > > - > > 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: releasing maven-artifact
I assume this is the current trunk and not the CAP branch? On 29/02/2008, at 5:34 PM, Jason van Zyl wrote: John/Mark, You have anything that you want to put in maven-artifact as I'm going to start making alphas. I'll take a look at the one issue scheduled for m-a, let you guys add anything you were working on and then squeeze it out to prepare for a 2.1-alpha-1. Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r631999 - in /maven/archiva/branches/springy: archiva-base/archiva-common/ archiva-base/archiva-configuration/src/test/java/org/apache/maven/archiva/configuration/ archiva-base/archiva
the reason in plexus was because each action was allocated on every request and not released - I just want to check whether that was the case again here. I think Olivier investigated it originally - is he listening here? :) - Brett On 29/02/2008, at 7:43 PM, nicolas de loof wrote: // Release existing -release( archivaConfiguration ); +// FIXME spring equivalent ? release( archivaConfiguration ); I don't know if spring takes care of managing them itself - but we need to look into this since we used to have leaks from the webapp when it never released the components. AFAIK there is no way in spring to "remove" a bean from the context. Not sure what is the requirement here, I suppose we want to FORCE the singleton "archivaConfiguration" bean to get reloaded / refreshed. The best option IMHO is to use use a BeanNameAutoProxyCreator to create a proxy for the "archivaConfiguration" singleton. An interceptor could cache the active concrete implementation instance, declared as prototype, and expose a "release()" management method to force a new lookup. Nicolas. -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
RE: Maven breaks after last night.
Hi guys, sorry to bother you again, but I resolved it: in one of the parent poms the assemble phase wasn't attached with the single goal. I changed it and now the build doesn't get forked. Once again to all that helped. Petar Tahchiev wrote: > > Well, everything seems fine, the single goal is attached to the phase: > > > > > > org.apache.maven.plugins > maven-assembly-plugin > 2.2-beta-1 > > > > src/assemble/main.xml > > > > > package > > single > > > > > > > > > and, again, I am sure that this was working a few days ago. > > > > > Brian E Fox wrote: >> >> What goal is bound to the phase? If it's assemble then there's the >> problem. You need to use single or attach instead >> >> -Original Message- >> From: Petar Tahchiev [mailto:[EMAIL PROTECTED] >> Sent: Thursday, February 28, 2008 4:40 PM >> To: dev@maven.apache.org >> Subject: Re: Maven breaks after last night. >> >> >> Hi guys, >> >> I found that after commenting the section containing the >> assembly >> plugin configuration in uberjar-12 module, the build gets forked on the >> next >> module containing build assembly configuration(uberjar-13). So the >> problem >> seems to be in the assembly plugin. I have no idea how is that possible, >> since assembly plugin hadn't had a release lately, and I use the same >> version of the plugin I as before ... >> >> >> >> >> >> Petar Tahchiev wrote: >>> >>> That is because the build gets forked before the required artifact >> gets >>> installed. >>> And the forked process requires the artifact. >>> >>> >>> Niall Pemberton-2 wrote: On Thu, Feb 28, 2008 at 7:05 PM, Petar Tahchiev >> <[EMAIL PROTECTED]> wrote: > > I checked the version of all the maven plugins that are used, and >> none > of the > plugins seems to be updated for the past month. > You can checkout the source of Cactus and try to build it by >> yourself: > > http://svn.apache.org/repos/asf/jakarta/cactus/trunk/ > > I upload the output of the build process. Actually it turned out >> that > the > build eventually ends, the problem is that it builds actually the > source > many times. If you look at the attachment you can see that on line >> 430 > in > stead of continuing with the next uberjar, the build starts again >> from > the > top level pom. This is really strange for me. > > I bet it's a really stupid mistake, but I cannot think of anything >> to > cause > this behaviour. I tried building cactus and got the following error: Missing: -- 1) >> org.apache.cactus:cactus.core.framework.javaEE.12-13-14:test-jar:tests:1 >> .8.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.cactus -DartifactId=cactus.core.framework.javaEE.12-13-14 -Dversion=1.8.0-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the >> file there: mvn deploy:deploy-file -DgroupId=org.apache.cactus -DartifactId=cactus.core.framework.javaEE.12-13-14 -Dversion=1.8.0-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) >> org.apache.cactus:cactus.core.framework.javaEE.13-14:jar:1.8.0-SNAPSHOT 2) >> org.apache.cactus:cactus.core.framework.javaEE.12-13-14:test-jar:tests:1 >> .8.0-SNAPSHOT -- 1 required artifact is missing. for artifact: >> org.apache.cactus:cactus.core.framework.javaEE.13-14:jar:1.8.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) > Thanks. > > http://www.nabble.com/file/p15743506/outp2 outp2 > > > > > > Niall Pemberton-2 wrote: > > > > On Thu, Feb 28, 2008 at 5:33 PM, Petar Tahchiev > <[EMAIL PROTECTED]> > > wrote: > >> > >> Hi guys, > >> > >> my build was working absolutely perfect yesterday. However, >> today > I > >> tri
Re: from plexus to spring...
I've setup a WebWorkPlexusInSpringObjectFactory to replace the spring ObjectFactory used by webwork and fix this lookup issue. The application works for basic requirements (configure admin, display repo configuration, download a jar from proxies). Still some exceptions to fix for missing plexus features ( PlexusContainer.addContextValue) Nicolas. 2008/2/29, nicolas de loof <[EMAIL PROTECTED]>: > > The problem is inverse : > > The bean is registered in spring context as Interface#role-hint (for > example : id="action#searchAction" for a webwork action bean) and the Spring > ObjectFactory ask for a bean with only the role-hint. > > A hack solution would be to use a custom SpringObejctFactory and search > the context for action# and interceptor#. > > Nico. > > 2008/2/28, Brett Porter <[EMAIL PROTECTED]>: > > > > It's a bit of a hack, but if a bean lookup fails for > > Something#something, can you just remove the trailing #something and > > try again? I assume this is the problem? > > > > > > - Brett > > > > > > On 29/02/2008, at 3:46 AM, nicolas de loof wrote: > > > > > That beeing said, with xwork xml files converted I can start archiva > > > and register my admin account RUNNING ON SPRING ! > > > > > > Hey Rahul, seems you can start using plexus-spring on Continuum ! > > > > > > Nicolas > > > > > > > > > 2008/2/28, nicolas de loof <[EMAIL PROTECTED]>: > > > Support for plexus to Properties added in plexus-spring, > > > > > > Now have the following error when first access to /archiva webapp : > > > > > > Caused by: java.lang.ClassNotFoundException: > > > redbackEnvironmentCheckInterceptor > > > at > > > org > > > .apache > > > .catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java: > > > 1352) > > > at > > > org > > > .apache > > > .catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java: > > > 1198) > > > at > > > com.opensymphony.util.ClassLoaderUtil.loadClass(ClassLoaderUtil.java: > > > 104) > > > at > > > com > > > .opensymphony > > > .xwork.ObjectFactory.getClassInstance(ObjectFactory.java:88) > > > at > > > com > > > .opensymphony > > > .xwork > > > .spring > > > .SpringObjectFactory.getClassInstance(SpringObjectFactory.java:175) > > > at > > > com > > > .opensymphony > > > .xwork.spring.SpringObjectFactory.buildBean(SpringObjectFactory.java: > > > 116) > > > > > > > > > The expected component is declared in redback-xwork-integration-1.0- > > > alpha-4.jar : > > > > > > > > > com.opensymphony.xwork.interceptor.Interceptor > > > redbackForceAdminUserInterceptor > > > ... > > > > > > Using the convention used to convert plexus rold+hint to spring IDs, > > > this result in a spring bean > > > id="interceptor#redbackForceAdminUserInterceptor". > > > > > > Editing xwork-security to use the expected IDs is not a valid > > > solution as this file comes from the war overlay. > > > > > > Any suggestion ? > > > > > > Nicolas. > > > > > > > > > > > > 2008/2/28, nicolas de loof <[EMAIL PROTECTED]>: > > > PlexusConfiguration support is now fixed. > > > > > > archiva-configuration tests pass with no change required, except : > > > > > > PlexusTestCase --> PlexusInSpringTestCase > > > add getSpringConfigLocation() to return path to the new spring- > > > context.xml test resource > > > > > > [INFO] > > > > > > > > [INFO] BUILD SUCCESSFUL > > > [INFO] > > > > > > > > > > > I've also created a PlexusWebApplicationContext and tried to start > > > archiva webapp with spring... but this is not so easy : > > > > > > change webwork.properties for : webwork.objectFactory = spring > > > change web.xml to remove PlexusLifecycleListener > > > use spring applicationContext to expose the PlexusContainerAdapter > > > as "webwork.plexus.container" > > > > > > The web application starts and initialize many beans, but fails > > > during security framework setup : > > > > > > "The JdoFactory property 'org.jpox.rdbms.dateTimezone' MUST BE Set > > > to 'JDK_DEFAULT_TIMEZONE' in order for jpox and JdoKeyManager to > > > operate correctly." > > > > > > The AbstractConfigurableJdoFactory requires conversion from plexus > > > elements to Properties... > > > > > > > > > Nicolas. > > > > > > > > > > > > > > > 2008/2/27, nicolas de loof <[EMAIL PROTECTED]>: > > > I just committed partial support for PlexusConfiguration : > > > > > > - as XML validation is disabled the XML configuration doesn't > > > require to be in a CDATA section > > > - the namespaceHandler detects structured configuration and creates > > > a DomPlexusConfiguration for it. > > > - Still have to implement DomPlexusConfiguration as > > > XmlPlexusConfiguration requires Xpp3Dom. > > > > > > Still some work on this feature and I expect to pass archiva- > > > configuration tests. > > > > > > Nico. > > > > > > > > > 2008/2/27, nicolas de loof <[EMAIL PROTECT
Re: releasing maven-artifact
Nope, go for it! Mark On 29/02/2008, Jason van Zyl <[EMAIL PROTECTED]> wrote: > John/Mark, > > You have anything that you want to put in maven-artifact as I'm going > to start making alphas. I'll take a look at the one issue scheduled > for m-a, let you guys add anything you were working on and then > squeeze it out to prepare for a 2.1-alpha-1. > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > jason at sonatype dot com > -- > > happiness is like a butterfly: the more you chase it, the more it will > elude you, but if you turn your attention to other things, it will come > and sit softly on your shoulder ... > > -- Thoreau > > > > > - > 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]
releasing maven-artifact
John/Mark, You have anything that you want to put in maven-artifact as I'm going to start making alphas. I'll take a look at the one issue scheduled for m-a, let you guys add anything you were working on and then squeeze it out to prepare for a 2.1-alpha-1. Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Paul Gier as Maven committer
+1 -Deng On Fri, Feb 29, 2008 at 3:21 AM, John Casey <[EMAIL PROTECTED]> wrote: > I'd like to propose giving commit access to Paul Gier. > > He's been instrumental in the recent push to release the assembly > plugin, and I see his work (debugging some issues, patches for other > issues) all over JIRA. Not to mention he's pretty active on IRC, and > he's helping people out on the users list as well. > > IMO, we need more people as involved as Paul has been, to keep Maven > humming along. > > Please vote. 72h +1/+0/-1 > > Here's my +1. > > -john > > --- > John Casey > Committer and PMC Member, Apache Maven > mail: jdcasey at commonjava dot org > blog: http://www.ejlife.net/blogs/john > rss: http://feeds.feedburner.com/ejlife/john > > >
