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
priv
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 cause
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 do you think?
Kind regards
Karl-Heinz Marbaise
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
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
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
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
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
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 herve.bout...@free.fr:
to me, it's clear we need some formal attribution to ASF from each major
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.
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 bimargul...@gmail.com
wrote:
I'm trying to avoid having this drift into the
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
On Sep 8, 2014, at 10:34 PM, Benson Margulies bimargul...@gmail.com wrote:
On Mon, Sep 8, 2014 at 10:27 PM, Jason van Zyl ja...@takari.io 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
On 2014-09-09, Jason van Zyl wrote:
On Sep 8, 2014, at 10:34 PM, Benson Margulies bimargul...@gmail.com 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
On 9 September 2014 12:42, Jason van Zyl ja...@takari.io wrote:
On Sep 8, 2014, at 10:34 PM, Benson Margulies bimargul...@gmail.com
wrote:
On Mon, Sep 8, 2014 at 10:27 PM, Jason van Zyl ja...@takari.io wrote:
You current CLA is sufficient. You'll the author of the code, you can
On Sep 9, 2014, at 8:00 AM, Stefan Bodewig bode...@apache.org wrote:
On 2014-09-09, Jason van Zyl wrote:
On Sep 8, 2014, at 10:34 PM, Benson Margulies bimargul...@gmail.com wrote:
Your CLA is sufficient if you, yourself, commit it to an Apache repo. Since
we're planning to push a repo
On Sep 9, 2014, at 8:02 AM, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
On 9 September 2014 12:42, Jason van Zyl ja...@takari.io wrote:
On Sep 8, 2014, at 10:34 PM, Benson Margulies bimargul...@gmail.com
wrote:
On Mon, Sep 8, 2014 at 10:27 PM, Jason van Zyl ja...@takari.io
On 2014-09-09, Jason van Zyl wrote:
On Sep 9, 2014, at 8:00 AM, Stefan Bodewig bode...@apache.org wrote:
On 2014-09-09, Jason van Zyl wrote:
On Sep 8, 2014, at 10:34 PM, Benson Margulies bimargul...@gmail.com wrote:
Your CLA is sufficient if you, yourself, commit it to an Apache repo.
On Sep 9, 2014, at 8:54 AM, Stefan Bodewig bode...@apache.org 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.
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 ja...@takari.io wrote:
On Sep 9, 2014, at 8:54 AM,
On 9 September 2014 14:01, Jason van Zyl ja...@takari.io wrote:
On Sep 9, 2014, at 8:54 AM, Stefan Bodewig bode...@apache.org 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
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
On Tue, Sep 9, 2014 at 9:15 AM, Jason van Zyl ja...@takari.io 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
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
On 9 September 2014 14:46, Jason van Zyl ja...@takari.io 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
On Tue, Sep 9, 2014 at 9:46 AM, Jason van Zyl ja...@takari.io 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
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
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
On Mon, Sep 8, 2014 at 7:32 PM, Hervé BOUTEMY herve.bout...@free.fr 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
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 herve.bout...@free.fr wrote:
here is the new version with csv files and committers
On Mon, Sep 8, 2014 at 10:27 PM, Jason van Zyl ja...@takari.io 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
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
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
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
around
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
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
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,
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 their
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
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
I'm
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 herve.bout...@free.fr wrote:
here are more accurate
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 a
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
On Wednesday, 3 September 2014, Hervé BOUTEMY herve.bout...@free.fr 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
On Wed, Sep 3, 2014 at 2:23 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On Wednesday, 3 September 2014, Hervé BOUTEMY herve.bout...@free.fr wrote:
is there something about IP process for such established code?
I see something like 10 components (we won't take
On Wednesday, 3 September 2014, Benson Margulies bimargul...@gmail.com
wrote:
On Wed, Sep 3, 2014 at 2:23 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On Wednesday, 3 September 2014, Hervé BOUTEMY herve.bout...@free.fr
wrote:
is there something about IP process for such
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,
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
On Wednesday, 3 September 2014, Benson Margulies bimargul...@gmail.com
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)
On Wed, Sep 3, 2014 at 3:02 AM, Karl Heinz Marbaise khmarba...@gmx.de 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
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
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
If _everyone_ is present and accounted for, I agree.
On Wed, Sep 3, 2014 at 3:01 PM, Jason van Zyl ja...@takari.io 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,
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 bimargul...@gmail.com wrote:
If
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 appear
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
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
kristian.rosenv...@gmail.com wrote:
We have started talking about moving them somewhere,
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 kristian.rosenv...@gmail.com
wrote:
We have started talking
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 bimargul...@gmail.com
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
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...
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
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 bimargul...@gmail.com wrote:
Gang, doesn't the board of the ASF have very strong, negative,
feelings about ASF PMC's controlling and maintaining code outside of
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
of plexus-components [1],
since this one is not the only one.
If we continue in the direction started for svn to git migration, can some
Sonatype github manager split plexus-components into 7 parts (plexus-
components will only be the parent)?
Regards,
Hervé
[1] https
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 the only one.
If we continue in the direction started for svn to git migration, can
some
Sonatype github manager split plexus
...@free.fr
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 situation overview of plexus-components [1],
since
, 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 12:50 PM, Benson Margulies
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 the only one
of plexus-components [1], since
this one is not the only one.
If we continue in the direction started for svn to git migration, can some
Sonatype github manager split plexus-components into 7 parts (plexus-
components will only be the parent)?
Regards,
Hervé
[1] https://cwiki.apache.org
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 the only one.
If we continue in the direction started
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 the only one.
If we continue in the direction started for svn to git migration
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
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
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 ja...@takari.io wrote:
The short answer is that you can't right now. We do not
-
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
provenance for the plexus components required by the 3.0
@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 the plexus components required by the 3.0 maven embedder.
I suppose that the Apache Foundation has already done similar provenance
checks before
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 team is having a hard time trying
On Sat, Feb 28, 2009 at 8:28 PM, Arnaud HERITIER aherit...@gmail.com 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
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
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
: 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
provenance for the plexus components required by the 3.0 maven
@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 the plexus components required by the 3.0 maven embedder.
I suppose that the Apache Foundation has already done similar provenance
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 second JAR from newer versions of Plexus
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
use
plexus
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 through its dependencies.
Here's the current output of 'mvn dependency:tree':
[INFO] [dependency:tree
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 caused so many
[ 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 embedder
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
-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 the
most part, just being used
-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 used, for the
most part, just
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
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 phase,
dependencyresolution required)
Any
of 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/
|_ mojos
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?
Also some of these projects use plexus components
95 matches
Mail list logo
