maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: MRELEASE-431
Date Mon, 24 Mar 2014 09:31:49 GMT
Hi again Robert,

I checked in the odd-even module in r1580793 - every
feedback/suggestion/... is, as usual, much more than welcome and
appreciated :)

All the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi


On Sat, Mar 22, 2014 at 1:10 PM, Robert Scholte <rfscholte@apache.org> wrote:
> Hi Simone,
>
> I've added the projectVersionPolicyId to the releaseDescriptor. We might
> need to add dependencyVersionPolicyId, parentVersionPolicyId and
> pluginVersionPolicyId in the future as well.
> So the manager is ready to switch from implementation, which should be
> enough for unittesting.
> We still need to make it available for the plugin.
>
> I think most version policies should have their own project+release-cycle,
> but it seems like the odd-even is a common policy, so I don't mind making it
> a separate module which will be part of the maven-release project.
> We can probably do something like enforcer: make a standard-policies module
> with common implementation.
> Although for now I wouldn't make it add it as dependency to the manager,
> users can do that themselves if they want.
>
> Robert
>
>
> Op Fri, 21 Mar 2014 12:56:02 +0100 schreef Simone Tripodi
> <simonetripodi@apache.org>:
>
>
>> Hi again Robert,
>>
>> IIUC the VersionPolicy resolution in `Map<String, VersionPolicy>
>> versionPolicies` is strict to "default" only, moreover I didn't
>> understand where/how to specify, in the plugin configuration, the
>> `hint` of my VersionPolicy implementation...
>>
>> As a side note, I already have, in my local copy of the source code, a
>> separated module with the odd-even policy implementation, included in
>> the build - if there are not objections, I'd commit it, just let me
>> know!
>>
>> All the best!
>> -Simo
>> http://people.apache.org/~simonetripodi/
>> http://twitter.com/simonetripodi
>>
>>
>> On Mon, Mar 17, 2014 at 10:51 PM, Robert Scholte <rfscholte@apache.org>
>> wrote:
>>>
>>> Hi Simone,
>>>
>>> http://svn.apache.org/r1578613 contains the default implementation for
>>> the
>>> maven-release-manager.
>>> Now it should be quite easy to test other policies.
>>>
>>> thanks,
>>>
>>> Robert
>>>
>>> ps. Alles Gute? Ja, alles goed ;) (my name looks too German, I guess)
>>>
>>> Op Mon, 17 Mar 2014 09:30:15 +0100 schreef Simone Tripodi
>>> <simonetripodi@apache.org>:
>>>
>>>
>>>> Hi Robert,
>>>>
>>>> after an internal discussion with  my colleagues, we are ATM fine with
>>>> just implementing the odd-even policy, so let's forget my prototype
>>>> ATM, we are fine with current new APIs.
>>>>
>>>> Is there anything I can help you in order to have them integrated in
>>>> the release-plugin?
>>>>
>>>> TIA, Alles Gute!
>>>> -Simo
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://twitter.com/simonetripodi
>>>>
>>>>
>>>> On Fri, Mar 14, 2014 at 3:03 PM, Simone Tripodi
>>>> <simonetripodi@apache.org> wrote:
>>>>>
>>>>>
>>>>> Hi Robert,
>>>>>
>>>>> yes I agree, while making my prototype - it will be opensourced, by
>>>>> the way - I also realised that my Policy implementation is the wrong
>>>>> Maven phase: when asking for the next release version, it is supposed
>>>>> that current doesn't exist yet (unless someone publishes the SNAPSHOT,
>>>>> even locally) so artifact diff cannot be executed.
>>>>> That would force users configuring the release plugin in order to
>>>>> invoke the `package` first...
>>>>>
>>>>> I don't have strong opinions ATM on how the new interface should look
>>>>> alike...
>>>>>
>>>>> Thanks a lot for you efforts!
>>>>> -Simo
>>>>>
>>>>> http://people.apache.org/~simonetripodi/
>>>>> http://twitter.com/simonetripodi
>>>>>
>>>>>
>>>>> On Fri, Mar 14, 2014 at 12:58 PM, Robert Scholte <rfscholte@apache.org>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Hi Simone,
>>>>>>
>>>>>> I think what you want is a way to make clear what kind of release
it
>>>>>> will
>>>>>> be: major, minor, bugfix/micro.
>>>>>> That's something which can be added to the request and looks
>>>>>> reasonable
>>>>>> for
>>>>>> all policies. I'm not sure if an enum is correct here, any founded
>>>>>> suggestion is welcome.
>>>>>> However, the calculation what kind of of release it should be, belongs
>>>>>> in
>>>>>> another class in my opinion.
>>>>>> So let's think of another interface :)
>>>>>>
>>>>>> Robert
>>>>>>
>>>>>>
>>>>>> Op Fri, 14 Mar 2014 10:10:55 +0100 schreef Simone Tripodi
>>>>>> <simonetripodi@apache.org>:
>>>>>>
>>>>>>
>>>>>>> Hi Rob,
>>>>>>>
>>>>>>> thanks a lot for the detailed feedback, very appreciated :)
>>>>>>>
>>>>>>> I just realise I didn't pass you enough informations to better
>>>>>>> understand the new context we are working on: in the OSGi world,
>>>>>>> aside
>>>>>>> the odd-even policy, we would like to wrap BND[1] APis which
allow
>>>>>>> compare two bundles and understand, via bytecode analysis[2],
which
>>>>>>> should be the suggested version; that is why I need the
>>>>>>> ArtifactResolver, in order to get the latest released artifact
(or
>>>>>>> specify the version, somehow) and compare it to the one is going
to
>>>>>>> be
>>>>>>> released, in order let BND calculate the suggested version.
>>>>>>>
>>>>>>> I hope that scenario makes more clear why I asked how to inject
other
>>>>>>> components!
>>>>>>>
>>>>>>> All the best!
>>>>>>> -Simo
>>>>>>>
>>>>>>> [1] http://www.aqute.biz/Bnd/
>>>>>>> [2] http://www.aqute.biz/Bnd/Versioning
>>>>>>> http://people.apache.org/~simonetripodi/
>>>>>>> http://twitter.com/simonetripodi
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Mar 13, 2014 at 7:19 PM, Robert Scholte
>>>>>>> <rfscholte@apache.org>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> To say it in your own words: IMHO I think you're wrong here
;)
>>>>>>>>
>>>>>>>> Version policy is about calculating the next version based
on an
>>>>>>>> input
>>>>>>>> version.
>>>>>>>> These are valid examples:
>>>>>>>> default policy:
>>>>>>>> getReleaseVersion("1-SNAPSHOT") = 1
>>>>>>>> getReleaseVersion("1.0-SNAPSHOT") = 1.0
>>>>>>>> getReleaseVersion("1.0.0-SNAPSHOT") = 1.0.0
>>>>>>>> getDevelopmentVersion("1") = 2-SNAPSHOT
>>>>>>>> getDevelopmentVersion("1.0") = 1.1-SNAPSHOT
>>>>>>>> getDevelopmentVersion("1.0.0") = 1.0.1-SNAPSHOT
>>>>>>>>
>>>>>>>> odd-even
>>>>>>>> getReleaseVersion("1.0-SNAPSHOT") = 1.1
>>>>>>>> getDevelopmentVersion("1.1") = 1.2-SNAPSHOT
>>>>>>>>
>>>>>>>> the metadata gives the following opportunity:
>>>>>>>> suppose you're on 3.2-SNAPSHOT but want to release a bugfix.
In that
>>>>>>>> case
>>>>>>>> you'd like to return to the latest SNAPSHOT. So instead of
3.1.4 ->
>>>>>>>> 3.1.5-SNAPSHOT it'll be 3.1.4 -> 3.2-SNAPSHOT
>>>>>>>>
>>>>>>>> I think it's weird to depend the policy on the GAV. Just
choose a
>>>>>>>> proper
>>>>>>>> policy for your project.
>>>>>>>>
>>>>>>>> I also think that the ArtifactResolver is not required here.
>>>>>>>> It's like instead of passing a string-based version, you'd
like to
>>>>>>>> pass
>>>>>>>> an
>>>>>>>> artifact and extract it's version.
>>>>>>>> My idea is the other way around: extract the version from
the
>>>>>>>> artifact
>>>>>>>> first
>>>>>>>> and pass that to the policy.
>>>>>>>> I would expect it to be the version in the pom.xml. If you
want to
>>>>>>>> check
>>>>>>>> it,
>>>>>>>> use an enforcer rule or something like that.
>>>>>>>>
>>>>>>>> We should try to keep the task of this class as simple as
possible.
>>>>>>>>
>>>>>>>> Robert
>>>>>>>>
>>>>>>>> Op Thu, 13 Mar 2014 13:55:43 +0100 schreef Simone Tripodi
>>>>>>>> <simonetripodi@apache.org>:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi again Robert,
>>>>>>>>>
>>>>>>>>> sorry for bugging - I hope I don't :P - but I notice
Metadata also
>>>>>>>>> has
>>>>>>>>> a very limited subset of informations about the ongoing
released
>>>>>>>>> artifact.
>>>>>>>>> IMHO informations such us packaging and classifier should
be part
>>>>>>>>> of
>>>>>>>>> that data set - maybe I am wrong and work around that?
>>>>>>>>>
>>>>>>>>> TIA, All the best!
>>>>>>>>> -Simo
>>>>>>>>>
>>>>>>>>> http://people.apache.org/~simonetripodi/
>>>>>>>>> http://twitter.com/simonetripodi
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Mar 12, 2014 at 7:08 PM, Robert Scholte
>>>>>>>>> <rfscholte@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi Simone,
>>>>>>>>>>
>>>>>>>>>> for that reason I've added the Metadata, from which
you can get
>>>>>>>>>> the
>>>>>>>>>> latest
>>>>>>>>>> released artifact.
>>>>>>>>>> I really hope you don't need the ArtifactResolver.
>>>>>>>>>>
>>>>>>>>>> Robert
>>>>>>>>>>
>>>>>>>>>> Op Wed, 12 Mar 2014 13:30:12 +0100 schreef Simone
Tripodi
>>>>>>>>>> <simonetripodi@apache.org>:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi again Robert,
>>>>>>>>>>>
>>>>>>>>>>> in one of my VersionPolicy implementations, I
need to resolve the
>>>>>>>>>>> latest release artifact - then I have a tool
to compare the
>>>>>>>>>>> bytecodes
>>>>>>>>>>> and automatically understand which is the release
number.
>>>>>>>>>>>
>>>>>>>>>>> Question is: while I need an ArtifactResolver,
I also need
>>>>>>>>>>> ArtifactRepository for local/remotes that, inside
a MOJO, would
>>>>>>>>>>> be
>>>>>>>>>>> get
>>>>>>>>>>> via the code below... what are the related Plexus
annotations, in
>>>>>>>>>>> order to obtain the same components?
>>>>>>>>>>>
>>>>>>>>>>> TIA, all the best!
>>>>>>>>>>> -Simo
>>>>>>>>>>>
>>>>>>>>>>>     @Parameter(required = true, defaultValue
=
>>>>>>>>>>> "${localRepository}",
>>>>>>>>>>> readonly = true)
>>>>>>>>>>>     private ArtifactRepository localRepository;
>>>>>>>>>>>
>>>>>>>>>>>     @Parameter(required = true, defaultValue
=
>>>>>>>>>>> "${project.remoteArtifactRepositories}", readonly
= true)
>>>>>>>>>>>     private List<ArtifactRepository> remoteRepositories;
>>>>>>>>>>> http://people.apache.org/~simonetripodi/
>>>>>>>>>>> http://twitter.com/simonetripodi
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Mar 10, 2014 at 7:09 PM, Robert Scholte
>>>>>>>>>>> <rfscholte@apache.org>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Simone,
>>>>>>>>>>>>
>>>>>>>>>>>> I still have to find a solution for the VersionParseException
>>>>>>>>>>>> which
>>>>>>>>>>>> can
>>>>>>>>>>>> be
>>>>>>>>>>>> thrown with the current implementation of
DefaultVersionInfo. I
>>>>>>>>>>>> probably
>>>>>>>>>>>> have to add it to both methods of VersionPolicy
>>>>>>>>>>>>
>>>>>>>>>>>> Your custom implementation will look something
like:
>>>>>>>>>>>>
>>>>>>>>>>>> @Component( role = VersionPolicy.class, hint
= "tripodi" )
>>>>>>>>>>>> public class TripodiVersionPolicy implements
VersionPolicy {
>>>>>>>>>>>>  // your stuff
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> The plugin will get parameters like projectVersionPolicyId
>>>>>>>>>>>> and/or
>>>>>>>>>>>> dependencyVersionPolicyId.
>>>>>>>>>>>> At least, that's my idea right now to split
it up per type. This
>>>>>>>>>>>> way
>>>>>>>>>>>> implementations can stay as clean as possible.
>>>>>>>>>>>>
>>>>>>>>>>>> Robert
>>>>>>>>>>>>
>>>>>>>>>>>> Op Mon, 10 Mar 2014 14:17:43 +0100 schreef
Simone Tripodi
>>>>>>>>>>>> <simonetripodi@apache.org>:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi again Robert,
>>>>>>>>>>>>>
>>>>>>>>>>>>> new APIs look reasonable and easily extensible
to me, thanks
>>>>>>>>>>>>> for
>>>>>>>>>>>>> putting
>>>>>>>>>>>>> effort on that!
>>>>>>>>>>>>> I maybe missed something but I didn't
notice how they are
>>>>>>>>>>>>> integrated
>>>>>>>>>>>>> in
>>>>>>>>>>>>> the
>>>>>>>>>>>>> core module...
>>>>>>>>>>>>> TIA all the best!
>>>>>>>>>>>>> -Simo
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://people.apache.org/~simonetripodi/
>>>>>>>>>>>>> http://twitter.com/simonetripodi
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sat, Mar 8, 2014 at 3:17 PM, Robert
Scholte
>>>>>>>>>>>>> <rfscholte@apache.org>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Simone,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've added a new module for Maven
release policies including
>>>>>>>>>>>>>> my
>>>>>>>>>>>>>> idea
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>> how the API should look like.
>>>>>>>>>>>>>> Although one of my suggestions to
specify this as an
>>>>>>>>>>>>>> implementation
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> plugin configuration, I now prefer
to use it as a component.
>>>>>>>>>>>>>> Downside
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>> that you can't use a pojo, you'll
need to add Plexus
>>>>>>>>>>>>>> annotations
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> generate the descriptor. However,
now you can inject other
>>>>>>>>>>>>>> components
>>>>>>>>>>>>>> a.k.a
>>>>>>>>>>>>>> requirements. Since this might become
quite complicated,
>>>>>>>>>>>>>> injection
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>> probably the preferred way.
>>>>>>>>>>>>>> I probably need more info in the
PolicyRequest to support the
>>>>>>>>>>>>>> current
>>>>>>>>>>>>>> behavior, but this is just a start.
>>>>>>>>>>>>>> This should be a good start for you
too. Let me know if this
>>>>>>>>>>>>>> will
>>>>>>>>>>>>>> work
>>>>>>>>>>>>>> with your requirements.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> best,
>>>>>>>>>>>>>> Robert
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Op Fri, 28 Feb 2014 17:06:05 +0100
schreef Simone Tripodi <
>>>>>>>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  Hi Rob! :)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> indeed it has been a very long
while, so sorry for that :(
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> OK I understand your PoV, count
on me if you want to
>>>>>>>>>>>>>>> co-operate
>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>> need
>>>>>>>>>>>>>>> that feature as well in order
to make the release-plugin able
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> generate
>>>>>>>>>>>>>>> that version using a tool, but
without exposing such APIs
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> allow
>>>>>>>>>>>>>>> me
>>>>>>>>>>>>>>> plugging different versioning
systems, I cannot do it :)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Many thanks in advance and have
a nice weekend!
>>>>>>>>>>>>>>> All the best!
>>>>>>>>>>>>>>> -Simo
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://people.apache.org/~simonetripodi/
>>>>>>>>>>>>>>> http://twitter.com/simonetripodi
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Feb 28, 2014 at 4:17
PM, Robert Scholte
>>>>>>>>>>>>>>> <rfscholte@apache.org
>>>>>>>>>>>>>>> >wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  Hi Simone,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It's been a while, so I'll
need to have another look at
>>>>>>>>>>>>>>>> this.
>>>>>>>>>>>>>>>> At first glance I'm not yet
happy with the suggested API.
>>>>>>>>>>>>>>>> I'd need to make some time
so come with a final solution.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Robert
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Op Fri, 28 Feb 2014 14:56:35
+0100 schreef Simone Tripodi <
>>>>>>>>>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  Hi all mates,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I am in a phase where
I could get benefit of that feature
>>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>> well
>>>>>>>>>>>>>>>>> (and,
>>>>>>>>>>>>>>>>> since I am still in the
committer list, I can provide some
>>>>>>>>>>>>>>>>> help
>>>>>>>>>>>>>>>>> here)
>>>>>>>>>>>>>>>>> so I
>>>>>>>>>>>>>>>>> would like to push it
:P
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> @Robert: before merging
the contribution we received in
>>>>>>>>>>>>>>>>> JIRA,
>>>>>>>>>>>>>>>>> I'd
>>>>>>>>>>>>>>>>> kindly
>>>>>>>>>>>>>>>>> ask if you had a better
idea if new API has to be in
>>>>>>>>>>>>>>>>> the maven-release-manager
or in a separate module.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Many thanks in advance,
all the best!
>>>>>>>>>>>>>>>>> -Simo
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://people.apache.org/~simonetripodi/
>>>>>>>>>>>>>>>>> http://twitter.com/simonetripodi
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>>>> For additional commands,
e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail:
dev-help@maven.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message