Is it possible to Inject Maven paramaters into Plexus components
I've tried this without success. Both repoSession and repositories are null
@Component(role = ResolverComponent.class, instantiationStrategy =
"per-lookup")
public class ResolverComponent {
@Requirement
great having a small mail here on the dev list to be informed
> about new releases of the plexus components cause many plugins are using
> them so it's simpler to follow and to decide to update plugins with new
> versions...
>
> What d
Hi,
i have a suggestioncurrently there are changes on going in plexus
parts (really good Thanks Kristian...)...but it's hard to know when a
new release is out...
It would be great having a small mail here on the dev list to be
informed about new releases of the plexus components
work done:
http://people.apache.org/~hboutemy/codehaus/summary.html
after author stats for each component, there is the shortlog for patches
applied
now we need to prepare attribution thread, to let a maximum of contributors
express their desire to give their contribution to ASF.
Any proposal f
Le jeudi 11 septembre 2014 08:40:42 Kristian Rosenvold a écrit :
> Excellent proposal Hervé, but how do we deal with jira-based
> submissions ? I am probably @author of half my committs and @committer
> of the rest ?
given we have the "Submitted by" stanza for svn, we should be able to count
these
Excellent proposal Hervé, but how do we deal with jira-based
submissions ? I am probably @author of half my committs and @committer
of the rest ?
Kristian
2014-09-11 8:10 GMT+02:00 Hervé BOUTEMY :
> to me, it's clear we need some formal attribution to ASF from each major
> contributor, since th
I agree that it is about projects migrating dependencies - which can take
awhile, to put it mildly.
However, migrating package names at the same time as migrating groupIDs can
go a long way towards avoiding ClassCastExceptions.
That would - in turn - imply that a new major version number is requir
When/if we move these components I assume they will get a new groupId? Will
that not cause issues with duplicated plexus libraries (due to two
different sets of GA) until "everything" has moved over to the new
dependencies?
/Anders
On Thu, Sep 11, 2014 at 8:10 AM, Hervé BOUTEMY
wrote:
> to me,
to me, it's clear we need some formal attribution to ASF from each major
contributor, since the code was committed to Codehaus, not ASF, and Codehaus
is not an antity that can transfer the result to ASF
for the formal part, without being a lawyer, I suppose each constributor has
to confirm he i
I'll leave to you guys. My only suggestion is to make a submission package that
contains:
- references to the repos
- userids those with CLAs on file
- userids of new CLAs along with those CLAs
Send out an email with a pointer to a repo with the same perms as Plexus where
people can add their u
On Tue, Sep 9, 2014 at 9:46 AM, Jason van Zyl wrote:
> There have been companies who have submitted bodies of code to Apache, and
> there have been projects consisting of individuals submitting bodies of
> code. We're not doing anything new. The Apache Incubator can be used for
> this case and th
On 9 September 2014 14:46, Jason van Zyl wrote:
> There have been companies who have submitted bodies of code to Apache,
And those companies usually have a CLA from their contributors or else all
the contributors are employees and the code is thus owned by the company
> and there have been pr
There have been companies who have submitted bodies of code to Apache, and
there have been projects consisting of individuals submitting bodies of code.
We're not doing anything new. The Apache Incubator can be used for this case
and there are likely people there who have dealt with this case an
On Tue, Sep 9, 2014 at 9:15 AM, Jason van Zyl wrote:
> I don't think we should attempt to make up new procedures here. Just use
> the standard Apache Incubation process if you're going to move a body of
> code. I don't think it will take long and then all the bases are covered
> and everyone else
I don't think we should attempt to make up new procedures here. Just use the
standard Apache Incubation process if you're going to move a body of code. I
don't think it will take long and then all the bases are covered and everyone
else there can inspect the procedure.
On Sep 9, 2014, at 9:08 A
On 9 September 2014 14:01, Jason van Zyl wrote:
> On Sep 9, 2014, at 8:54 AM, Stefan Bodewig wrote:
>
> > When every contributors so by him/herself, sure. "submitted by YOU".
> >
>
> Same meaning if Hervé pushed the repo in here and we've all agreed.
The key bit is "we've all agreed" where th
I suggest that we just use the existing Apache Incubation process. The
procedure is already well laid out, and if that is followed then we should be
fine. We don't need to invent anything new here.
On Sep 9, 2014, at 9:01 AM, Jason van Zyl wrote:
> On Sep 9, 2014, at 8:54 AM, Stefan Bodewig w
On Sep 9, 2014, at 8:54 AM, Stefan Bodewig wrote:
> When every contributors so by him/herself, sure. "submitted by YOU".
>
Same meaning if Hervé pushed the repo in here and we've all agreed. Again, this
is how the incubation process works to move a body of code to Apache. Everyone
doesn't re
On 2014-09-09, Jason van Zyl wrote:
> On Sep 9, 2014, at 8:00 AM, Stefan Bodewig wrote:
>> On 2014-09-09, Jason van Zyl wrote:
>>> On Sep 8, 2014, at 10:34 PM, Benson Margulies wrote:
Your CLA is sufficient if you, yourself, commit it to an Apache repo. Since
we're planning to push
On Sep 9, 2014, at 8:02 AM, Stephen Connolly
wrote:
> On 9 September 2014 12:42, Jason van Zyl wrote:
>
>>
>> On Sep 8, 2014, at 10:34 PM, Benson Margulies
>> wrote:
>>
>>> On Mon, Sep 8, 2014 at 10:27 PM, Jason van Zyl wrote:
>>>
You current CLA is sufficient. You'll the author of
On Sep 9, 2014, at 8:00 AM, Stefan Bodewig wrote:
> On 2014-09-09, Jason van Zyl wrote:
>
>> On Sep 8, 2014, at 10:34 PM, Benson Margulies wrote:
>
>>> Your CLA is sufficient if you, yourself, commit it to an Apache repo. Since
>>> we're planning to push a repo full of contributions from gith
On 9 September 2014 12:42, Jason van Zyl wrote:
>
> On Sep 8, 2014, at 10:34 PM, Benson Margulies
> wrote:
>
> > On Mon, Sep 8, 2014 at 10:27 PM, Jason van Zyl wrote:
> >
> >> You current CLA is sufficient. You'll the author of the code, you can
> >> contribute it to Apache. We need to find the
On 2014-09-09, Jason van Zyl wrote:
> On Sep 8, 2014, at 10:34 PM, Benson Margulies wrote:
>> Your CLA is sufficient if you, yourself, commit it to an Apache repo. Since
>> we're planning to push a repo full of contributions from github to apache,
>> the CLA is not enough on its own.
> Explain
On Sep 8, 2014, at 10:34 PM, Benson Margulies wrote:
> On Mon, Sep 8, 2014 at 10:27 PM, Jason van Zyl wrote:
>
>> You current CLA is sufficient. You'll the author of the code, you can
>> contribute it to Apache. We need to find the people on that list who do not
>> have a CLA on file.
>>
>
>
I'm not entirely sure I understand what you're saying, Benson.
When it comes to the actual committers in plexus, there's only one or
two names I haven't seen as frequent and active java community
members. Herve lists "authors", which in the case of git includes all
contributors, even one-line doc
The advantage of the patch approach is that, where the license is
compatible, we can still be ok for "small/trivial/obvious" contributions if
we can't establish contact IIUC
On Tuesday, 9 September 2014, Benson Margulies
wrote:
> I'm trying to avoid having this drift into the full 'IP clearance'
I'm trying to avoid having this drift into the full 'IP clearance' process
which is used for 'significant' contributions, on the grounds that each
individual's contribution isn't all that big. So I'm modeling this on a
patch sent to the mailing list, which requires no CLA and no fancy tracking.
O
So we make some kind of letter we send out to everyone with a reply-to
dev@maven ? Should we make a wiki page where we try to collect a
little more information about the different people (like email
addresses - better obfuscate them ,somehow:)
I would happily write one but I tend to mess up any ti
On Mon, Sep 8, 2014 at 10:27 PM, Jason van Zyl wrote:
> You current CLA is sufficient. You'll the author of the code, you can
> contribute it to Apache. We need to find the people on that list who do not
> have a CLA on file.
>
Your CLA is sufficient if you, yourself, commit it to an Apache repo
You current CLA is sufficient. You'll the author of the code, you can
contribute it to Apache. We need to find the people on that list who do not
have a CLA on file.
On Sep 8, 2014, at 7:32 PM, Hervé BOUTEMY wrote:
> here is the new version with csv files and committers deduplicate
> http://pe
On Mon, Sep 8, 2014 at 7:32 PM, Hervé BOUTEMY wrote:
> here is the new version with csv files and committers deduplicate
> http://people.apache.org/~hboutemy/codehaus/summary.html
>
> now we need to ask for everybody's attribution of his contributions, and we'll
> see how much we cover from each c
here is the new version with csv files and committers deduplicate
http://people.apache.org/~hboutemy/codehaus/summary.html
now we need to ask for everybody's attribution of his contributions, and we'll
see how much we cover from each component
some components should be easy to cover fully, like
improved the automatic summary
http://people.apache.org/~hboutemy/codehaus/summary.html
I suppose the next step will be to create a csv to be able to work on figures
with a spreadsheet
I have no time at the moment, will try tomorrow if nobody beats me
Regards,
Hervé
Le dimanche 7 septembre 20
On Sun, Sep 7, 2014 at 2:24 PM, Kristian Rosenvold <
kristian.rosenv...@gmail.com> wrote:
> But I still assume we need to get some kind of idea of how good is
> good enough. At some point there's going to be a significant
> contributor we won't be able to get hold of. We might be able to work
> ar
But I still assume we need to get some kind of idea of how good is
good enough. At some point there's going to be a significant
contributor we won't be able to get hold of. We might be able to work
around this by removing code or similar, but I don't think there is
any point in starting a massive s
Cool, with your tool can you aggregate that into a single list of userIds/Names
and then remove us.
I recognize most of the non-us and with that list we can contact them all at
once if we want.
On Sep 6, 2014, at 5:05 PM, Hervé BOUTEMY wrote:
> here are more accurate statistics:
> http://peop
here are more accurate statistics:
http://people.apache.org/~hboutemy/codehaus
Le samedi 6 septembre 2014 09:39:20 Hervé BOUTEMY a écrit :
> I satrted to write down the count of contributors done by github, with link,
> on https://cwiki.apache.org/confluence/display/MAVEN/Plexus+dependencies
>
>
Plexus-* is huge. so while we /may/ choose to do single efforts like moving
maven core of the 5 specific classes in p-u,I simply do not see us moving
everything off plexus. I tend to consider that effort to be wasteful use of
energy. So creating a decent home for plexus is overall a better strategy
Le samedi 6 septembre 2014 19:31:14 Barrie Treloar a écrit :
> Wasn't there talk a while ago to remove Plexus entirely with more
> maintained and up-to-date equivalents?
yes, and the work even started with shared-utils to replace plexus-utils
>
> Would it be simpler to leave the artifacts at thei
Wasn't there talk a while ago to remove Plexus entirely with more
maintained and up-to-date equivalents?
Would it be simpler to leave the artifacts at their existing locations and
make minor changes there, and instead migrate away?
I've paid zero attention as to how much work, or how feasible, th
I satrted to write down the count of contributors done by github, with link,
on https://cwiki.apache.org/confluence/display/MAVEN/Plexus+dependencies
I'm not sure figures are relevant:
- missing contributions? it seems so, I looked at plexus-velocity and older
commits are not counted...
- every
ok, so how do we do the next step?
Regards,
Hervé
Le jeudi 4 septembre 2014 06:49:02 Kristian Rosenvold a écrit :
> I had a look through a few projects, and it would seem to me like
> "know" 90% of the committers because they are all associated with
> maven, most of them are also active. There's
I had a look through a few projects, and it would seem to me like
"know" 90% of the committers because they are all associated with
maven, most of them are also active. There's a further 5 or so
committers that are well known community folks that we could probably
get hold of easily. It would appea
For everything significant where significant is defined as more than 200 lines.
I don't think we have any of those, and if we actually expunged from the source
classes we don't actually use we're definitely safe.
On Sep 3, 2014, at 3:27 PM, Benson Margulies wrote:
> If _everyone_ is present an
If _everyone_ is present and accounted for, I agree.
On Wed, Sep 3, 2014 at 3:01 PM, Jason van Zyl wrote:
> Yes, I think everyone is making this 10x more complicated than it is. Our
> existing CLAs apply. If you wrote the code, you can contribute it. For
> modello, plexus-utils, and plexus-clas
Yes, I think everyone is making this 10x more complicated than it is. Our
existing CLAs apply. If you wrote the code, you can contribute it. For modello,
plexus-utils, and plexus-classworlds we're covered as far as I can tell.
On Sep 3, 2014, at 2:44 PM, Kristian Rosenvold
wrote:
> To my best
To my best knowledge, *all* of the substantial contributors to all the
plexus repositories I have seen are available to us, most of them are
PMC's or emeritus, and still "around" in some fashion or another.
Could we make all of them submit some kind of written submission to
the ASF ? I would actua
On Wed, Sep 3, 2014 at 3:02 AM, Karl Heinz Marbaise wrote:
> Hi,
>
>
> On 9/2/14 11:18 PM, Benson Margulies wrote:
>>
>> Gang, doesn't the board of the ASF have very strong, negative,
>> feelings about ASF PMC's controlling and maintaining code outside of
>> the ASF?
>
>
> Is there any evident abo
On Wednesday, 3 September 2014, Benson Margulies
wrote:
> Actually, that's really bad news.
>
> When a person creates a work, the copyright belongs to the person,
> unless that person enters into a contract to assign the contract to
> someone else.
>
> When I see 'Copyright (c) Codehaus', I a
Hi,
On 9/2/14 11:18 PM, Benson Margulies wrote:
Gang, doesn't the board of the ASF have very strong, negative,
feelings about ASF PMC's controlling and maintaining code outside of
the ASF?
Is there any evident about that ? any official statement about that from
ASF Board ?
> I confess that
Actually, that's really bad news.
When a person creates a work, the copyright belongs to the person,
unless that person enters into a contract to assign the contract to
someone else.
When I see 'Copyright (c) Codehaus', I assume that this is legit,
and that (a) Codehaus is a legal entity, and
On Wednesday, 3 September 2014, Benson Margulies
wrote:
> On Wed, Sep 3, 2014 at 2:23 AM, Stephen Connolly
> wrote:
> > On Wednesday, 3 September 2014, Hervé BOUTEMY
> wrote:
> >
> >> is there something about IP process for such established code?
> >>
> >> I see something like 10 components (we
On Wed, Sep 3, 2014 at 2:23 AM, Stephen Connolly
wrote:
> On Wednesday, 3 September 2014, Hervé BOUTEMY wrote:
>
>> is there something about IP process for such established code?
>>
>> I see something like 10 components (we won't take plexus-containers)
>> https://cwiki.apache.org/confluence/disp
On Wednesday, 3 September 2014, Hervé BOUTEMY wrote:
> is there something about IP process for such established code?
>
> I see something like 10 components (we won't take plexus-containers)
> https://cwiki.apache.org/confluence/display/MAVEN/Plexus+dependencies
>
> And what about the fact that i
is there something about IP process for such established code?
I see something like 10 components (we won't take plexus-containers)
https://cwiki.apache.org/confluence/display/MAVEN/Plexus+dependencies
And what about the fact that it is not in org.apache and not Apache License?
I'm really willin
Can we not just pull the code in? IIUC it is pretty much only us that uses
the code...
On 2 September 2014 22:18, Benson Margulies wrote:
> Gang, doesn't the board of the ASF have very strong, negative,
> feelings about ASF PMC's controlling and maintaining code outside of
> the ASF? I confess
Gang, doesn't the board of the ASF have very strong, negative,
feelings about ASF PMC's controlling and maintaining code outside of
the ASF? I confess that I found this whole topic extremely confusing,
what with the googlecode 'Apache Extras' business. We might want to
ask for some clarification be
Hi,
On 9/2/14 2:56 PM, Jason van Zyl wrote:
I asked Github to give us github.com/maven for our 3rd party code but someone
is using it. Maybe Hervé can setup github.com/apachemaven and we can move those
Git repositories there.
Unfortunately github.com/apachemaven is also occupied already...
Hi,
On 9/2/14 6:17 PM, Brian Fox wrote:
Herve and I discussed moving the repos before splitting them, but it
made sense to just go ahead and split it first because that was easier
and quicker to pull off. If we can get them into an Apache repo, that
makes sense.
Sounds great to me...github.com
Herve and I discussed moving the repos before splitting them, but it
made sense to just go ahead and split it first because that was easier
and quicker to pull off. If we can get them into an Apache repo, that
makes sense.
On Tue, Sep 2, 2014 at 3:48 AM, Benson Margulies wrote:
> Note that we rec
I asked Github to give us github.com/maven for our 3rd party code but someone
is using it. Maybe Hervé can setup github.com/apachemaven and we can move those
Git repositories there.
On Sep 2, 2014, at 3:09 AM, Kristian Rosenvold
wrote:
> We have started talking about moving them somewhere, an
Note that we recently split the repos up at Sonatype to make this less
cumbersome; Brian hands out access pretty much on request. At least,
he did for _me_.
On Tue, Sep 2, 2014 at 3:09 AM, Kristian Rosenvold
wrote:
> We have started talking about moving them somewhere, and the time may
> have com
We have started talking about moving them somewhere, and the time may
have come tom restart that discussion.
You can either ask Brian for access or have one of the existing
committers apply your pull request. Just a regular pull request from
github should do.
Kristian
2014-09-01 22:37 GMT+02:00
Hi,
i just want to know how we handle things which are located in components
like plexus-archiver etc.
Currently i'm diving into some problems and want to checkin some
improvments on the plexus-archiver...
How can i gain commit access to those components ?
Kind regards
Karl-Heinz Marbaise
orrow, and we'll be able to delete content from old plexus-
components location
Thank you Benson for this great work
Regards,
Hervé
Le lundi 18 août 2014 13:05:41 Benson Margulies a écrit :
> All done. plexus-swizzle fails unit tests, does anyone care?
>
>
> On Mon, Aug 18, 2014 at
per hosting location for
>>>>> this really is. If we want to move this to the maven project, I would
>>>>> support that.
>>>>>
>>>>> On Fri, Aug 1, 2014 at 6:09 AM, Hervé BOUTEMY
>>>>> wrote:
>>>>> > Hi,
>>>
discussion on where the proper hosting location for
>>>> this really is. If we want to move this to the maven project, I would
>>>> support that.
>>>>
>>>> On Fri, Aug 1, 2014 at 6:09 AM, Hervé BOUTEMY
>>>> wrote:
>>>> > Hi,
>>&g
t;> > Hi,
>>> >
>>> > While working on Checkstyle, I need to fix concurrency issues on plexus-
>>> > resources, but actual SCM situation doesn't permit it since it's in github
>>> > but not in its own repository.
>>> >
>
, Aug 1, 2014 at 6:09 AM, Hervé BOUTEMY wrote:
>> > Hi,
>> >
>> > While working on Checkstyle, I need to fix concurrency issues on plexus-
>> > resources, but actual SCM situation doesn't permit it since it's in github
>> > but not in its own
> Hi,
> >
> > While working on Checkstyle, I need to fix concurrency issues on plexus-
> > resources, but actual SCM situation doesn't permit it since it's in github
> > but not in its own repository.
> >
> > Then I reworked the overall situation overview
2014 at 6:09 AM, Hervé BOUTEMY wrote:
> Hi,
>
> While working on Checkstyle, I need to fix concurrency issues on plexus-
> resources, but actual SCM situation doesn't permit it since it's in github but
> not in its own repository.
>
> Then I reworked the overall sit
Hi,
While working on Checkstyle, I need to fix concurrency issues on plexus-
resources, but actual SCM situation doesn't permit it since it's in github but
not in its own repository.
Then I reworked the overall situation overview of plexus-components [1], since
this one is not th
Thanks a lot for the clarification Jason, much more than appreciated!
All the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Mon, Jun 23, 2014 at 3:00 PM, Jason van Zyl wrote:
> The short answer is that you can't right now. We do not create bindings in
The short answer is that you can't right now. We do not create bindings in the
normal JSR330 for configuration injection, we historically use a tool called
the PluginParameterExpressionEvaluator to pass over the component once it's
instantiated. We did this long before we used any container. As
Hi all mates,
I am a little lost and I would like to kindly ask you if anyone knows
how to request, via Plexus annotations, the injection of Maven
parameters/components.
While for components I guess it is more or less the same as in MOJOs,
just using different kind annotations, it is not clear to
On Sat, Feb 28, 2009 at 8:28 PM, Arnaud HERITIER wrote:
> Ok I understand. The problem is for commercial products based on Eclipse. I
> forgot that.For plexus it's annoying but it mustn't be to difficult to
> solve. The number of committers is limited and the major part is in the
> maven's team.
>
somehow review
> > the
> > code from third parties before distributing it (that's the Eclipse way).
> >
> >
> > Brian E Fox wrote:
> > >
> > > Plexus is a codehaus component, so Apache would most likely not have
> > these
>
n.apache.org
Subject: Code provenance checks for Plexus components
The Eclipse legal team is having a hard time trying to confirm code
provenance for the plexus components required by the 3.0 maven embedder.
I suppose that the Apache Foundation has already done similar provenance
checks bef
o Apache would most likely not have
> these
> > checks.
> >
> > -Original Message-
> > From: Abel Muiño [mailto:amu...@gmail.com]
> > Sent: Friday, February 27, 2009 1:18 PM
> > To: dev@maven.apache.org
> > Subject: Code provenance checks for Plexu
mailto:amu...@gmail.com]
> > Sent: Friday, February 27, 2009 1:18 PM
> > To: dev@maven.apache.org
> > Subject: Code provenance checks for Plexus components
> >
> >
> > The Eclipse legal team is having a hard time trying to confirm code
> > provenance for th
Original Message-
> From: Abel Muiño [mailto:amu...@gmail.com]
> Sent: Friday, February 27, 2009 1:18 PM
> To: dev@maven.apache.org
> Subject: Code provenance checks for Plexus components
>
>
> The Eclipse legal team is having a hard time trying to confirm code
> provenan
Plexus is a codehaus component, so Apache would most likely not have these
checks.
-Original Message-
From: Abel Muiño [mailto:amu...@gmail.com]
Sent: Friday, February 27, 2009 1:18 PM
To: dev@maven.apache.org
Subject: Code provenance checks for Plexus components
The Eclipse legal
The Eclipse legal team is having a hard time trying to confirm code
provenance for the plexus components required by the 3.0 maven embedder.
I suppose that the Apache Foundation has already done similar provenance
checks before distributing the components... so can you please help us with
the
s Lundberg [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 28, 2007 3:23 PM
> To: Maven Developers List
> Subject: Re: How to handle plexus-container-default and
> plexus-components-api dependencies in a shared component?
>
> Jason van Zyl wrote:
>> I have eliminated the se
3:23 PM
To: Maven Developers List
Subject: Re: How to handle plexus-container-default and
plexus-components-api dependencies in a shared component?
Jason van Zyl wrote:
> I have eliminated the second JAR from newer versions of Plexus, it was
a
> complete disaster separating the two and cau
;>
>> I'm going through the dependencies for shared/maven-archiver. Is a
>> shared component in danger of dragging in a wrong version of
>> plexus-container-default or plexus-components-api?
>>
>> The MavenArchiver class is not a plexus component itself, it doesn
Dec 07, Dennis Lundberg wrote:
Hi
I'm going through the dependencies for shared/maven-archiver. Is a
shared component in danger of dragging in a wrong version of
plexus-container-default or plexus-components-api?
The MavenArchiver class is not a plexus component itself, it doesn't
u
Hi
I'm going through the dependencies for shared/maven-archiver. Is a
shared component in danger of dragging in a wrong version of
plexus-container-default or plexus-components-api?
The MavenArchiver class is not a plexus component itself, it doesn't use
plexus directly - only t
[ http://jira.codehaus.org/browse/MNG-1665?page=all ]
Milos Kleint updated MNG-1665:
--
Attachment: custom-config.patch
> allow changing plexus components implementations dynamically through embed
allow changing plexus components implementations dynamically through embedder
-
Key: MNG-1665
URL: http://jira.codehaus.org/browse/MNG-1665
Project: Maven 2
Type: New Feature
Components
lexus/ (focus only on container and use mojos for extra services like
>zipping, etc)
>
>
The zipping etc are not mojos, they are pojos. There is really no
difference (they both plexus components, configured via a descriptor),
but mojos have additional metadata (goal name, lifecycle
Maczka Michal wrote:
>With exception for versioning it is all already implemented in plexus and
>just needs to be exposed.
>
>
If you look at the code before emailing, you'll save yourself a lot of
time. The plugin manager already uses plexus configuration to some
extent and has comments to move
> -Original Message-
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 13, 2005 12:30 AM
> To: Maven Developers List
> Subject: Re: [M2] Plugins vs Mojo vs Plexus components?
>
>
> This is really a name confusion. The plexus things being u
> -Original Message-
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: mercredi 13 avril 2005 00:30
> To: Maven Developers List
> Subject: Re: [M2] Plugins vs Mojo vs Plexus components?
>
> This is really a name confusion. The plexus things being used, for
gt;
>I see that several m2 plugins in maven-components/maven-*-plugin/** are
>using other java components located directly in maven-components/ such as
>maven-archiver, maven-archetype, etc. What are those projects? Are they
>Mojos? Of not, are they meant to become mojos in the future?
>
these projects use plexus components. For example,
maven-archiver use plexus' JarArchiver component. Will this be turned into a
Mojo that is independent of plexus too?
I would have imagined the following kind of directory structure in
maven-components:
maven-components/
|_ core/
|_
96 matches
Mail list logo
