Thats true,
The reason new developers/advanced users have to learn Plexus is to
create/configure plugins and dependecies. Having a more documented and
flexible plugin Api would make things simplier.
A firend of mine has created a custom maven plugin for a trivial task. He
took much of the dev time
My 2 cents. I happen to like Spring. I know Avalon really well which
Plexus has its roots in. That being said, I really don't care which one
is used as long as DI is really used, and that is where the problem is.
Things that should have been wired via configuration aren't (i.e.
DefaultArtifactV
tested with the released 2.4.3 at staging repo, no issue in my build.
+1
On Fri, May 2, 2008 at 4:23 PM, Dan Fabulich <[EMAIL PROTECTED]> wrote:
> Dan Tran wrote:
>
> > can i assume the snapshot is as good the staging one? .. I can have my
> > build to use it for a few days
> >
>
> Well, it's alw
Dan Tran wrote:
can i assume the snapshot is as good the staging one? .. I can have my
build to use it for a few days
Well, it's always better to use the real staging bits, blah blah blah but
I did a snapshot deploy about 30 seconds before I ran release:prepare, so
the snapshot build is prob
can i assume the snapshot is as good the staging one? .. I can have my
build to use it for a few days
-D
On Fri, May 2, 2008 at 2:14 PM, Dan Fabulich <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> We solved 11 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541&styleName=Html&versi
I think that would help.
Today the classpath issues seem greater with reporter (AbstractReporter)
plugins than plain Mojo plugins.
Regards,
Garvin LeClaire
[EMAIL PROTECTED]
John Casey wrote:
I think this issue would go away if we could write a plugin-facilities
api that gave easy acc
Hi,
We solved 11 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541&styleName=Html&version=14255
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10541&status=1
Staging repo:
http://people.apache.org/~dfab
I think this issue would go away if we could write a plugin-
facilities api that gave easy access to the things plugins need to do
in most cases. In other words, publish a formal, public api for Maven
for the plugin developer. While it'd be nice to have full design docs
for all of Maven, in
I have to say that I'm not at all interested in moving to Spring. At
all. I've used both Spring and Plexus, and while I don't think Plexus
is the end-all, be-all, it's better IMO than Spring. As far as
annotations go, I completely agree with Jason, that Annotations
should be standardized, a
My initial idea was not about Plexus vs Spring but to use OSGi as it
supports the plugin + isolation that is required for maven, and suggested
Spring because it allready supports OSGi.
If we can use plexus with OSGi, lets do it. I just would prefer plexus to be
less intrusive and to support annota
I would agree . Why spend time converting the core just to be on a
"more popular" framework. What would we do if Guice became more
popular, change again?
I think the bigger issue here is documentation on Maven's design and
design implementation. I find I have to search in a lot of place
>From the fiew documentation available, XBean seems to be a container for
jsr250-based components, with plugability for various IoC containers.
The "discover, download and install" plugin model seems to be very similar
to OSGi, and the link to Eclipse Equinox makes me suppose it's OSGi based
under
http://geronimo.apache.org/xbean
On Fri, May 2, 2008 at 1:04 PM, Hilco Wijbenga <[EMAIL PROTECTED]> wrote:
> On Fri, May 2, 2008 at 9:25 AM, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>
>
> > And ultimately the container DI is not the important part but the
> > implementations of our components.
On Fri, May 2, 2008 at 9:25 AM, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> And ultimately the container DI is not the important part but the
> implementations of our components. Using standard annotations for that is a
> good thing and that's not hard. XBR does full JEE injection and can manage
>
On Fri, May 2, 2008 at 3:47 PM, Luke Patterson <[EMAIL PROTECTED]> wrote:
> I agree that people would be more willing (and able) to contribute if the
> core technologies were "Java5 + Spring + OSGi".
>
>
> In the limited amount of time available to learn new things, is it
> worthwhile for one t
Within JBoss a lot of our projects use CR and GA so that the versions can be
sorted alphabetically. At least that was the explanation given to me ;)
I think RC is more common in other places. Ideally I would like to see a
pluggable version parsing so that a given project could configure it's
On 2-May-08, at 5:53 AM, nicolas de loof wrote:
[
]
Note to plexus lovers :
CONTROVERSAL PROPOSAL, please don't blame me and just give good
arguments !
[
--
I'd really love to see that, but that's not news at all ;)
On Fri, May 2, 2008 at 5:53 AM, nicolas de loof <[EMAIL PROTECTED]> wrote:
> [
>
>
> ]
> Note to plexus love
I agree that people would be more willing (and able) to contribute if the
core technologies were "Java5 + Spring + OSGi".
In the limited amount of time available to learn new things, is it
worthwhile for one to learn Plexus?
On 5/2/08, nicolas de loof <[EMAIL PROTECTED]> wrote:
>
> [
>
> --
[
]
Note to plexus lovers :
CONTROVERSAL PROPOSAL, please don't blame me and just give good arguments !
[
-
You could always namespace off system properties that should be passed
to the forked process, e.g. -Dtest.foo=bar would pass in -Dfoo=bar.
Mark
2008/5/2 Dan Fabulich <[EMAIL PROTECTED]>:
> Brett Porter wrote:
>
>
> > I thought I had commented on this at some point, but I don't really
> remember.
2008/5/2 Benjamin Bentmann <[EMAIL PROTECTED]>:
> Wayne Fay wrote:
>
>
> > How is CR different from RC?
> >
>
> I don't meant to say they are different, it's only another well-known
> qualifier, aliasing one from the existing list.
>
>
>
> > I think I'd pick one and forget about the other.
> >
>
>
Wayne Fay wrote:
How is CR different from RC?
I don't meant to say they are different, it's only another well-known
qualifier, aliasing one from the existing list.
I think I'd pick one and forget about the other.
Is an option, we only need to make sure to clearly explain people that Mave
Jörg Schaible wrote:
Maybe a new scope
+1 on that instead of some time-consuming ASM post analysis and POM
rewriting.
Benjamin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECT
24 matches
Mail list logo
