maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Chaffee <jason.chaf...@zilliontv.tv>
Subject Re: Re : Re : non-xml poms in 3.x
Date Mon, 07 Sep 2009 22:06:31 GMT
I understand that you probably don't want to commit to a date or cause
undue expectations from anyone on this list, so let me ask it in a
slight differently way.

Do you think it "might" be possible that we see a beta 3.x in 2009?

One reason I ask is because I would like to schedule some time in late
2009 for 3.x investigation , but if you know that it will not be
available by the end of 2009 then there is no reason to get into our
schedule.

kind regards,

Jason


On Sep 7, 2009, at 1:41 PM, Jason van Zyl wrote:

> No.
>
> On 2009-09-07, at 10:40 PM, Jason Chaffee wrote:
>
>> Any idea when this might be, approximately?
>>
>>
>> On Sep 7, 2009, at 1:36 AM, Jason van Zyl wrote:
>>
>>> No it's not available and won't be until I'm finished a fully
>>> working
>>> beta.
>>>
>>> On 2009-09-07, at 1:42 AM, Christian Edward Gruber wrote:
>>>
>>>> Is that prototype available?  I'd love to see it.
>>>>
>>>> Christian
>>>>
>>>> On 2009-09-06, at 18:53 , Jason Chaffee wrote:
>>>>
>>>>> Cool.  Good to hear.
>>>>>
>>>>>
>>>>> On Sep 5, 2009, at 1:42 PM, Jason van Zyl wrote:
>>>>>
>>>>>>
>>>>>> On 2009-09-05, at 10:23 PM, Jason Chaffee wrote:
>>>>>>
>>>>>>> I agree with you and Jason van Zyl about Maven probably doesn't
>>>>>>> need
>>>>>>> to support another option.  However, it would be nice if the
>>>>>>> architecture supported it more easily.
>>>>>>>
>>>>>>
>>>>>> It does and I used it in a prototype Groovy and JRuby sort of
>>>>>> version
>>>>>> of Maven
>>>>>>
>>>>>>> This would mean everything is accessed through a clean API and
>>>>>>> that
>>>>>>> we could easily inject our own POM parser.  If someone wrote
a
>>>>>>> plugin that didn't use the API's correct and bound to the XML,
>>>>>>> then
>>>>>>> the person that injected his own POM parser and POM format would
>>>>>>> be
>>>>>>> left to deal with that too.  He/She would have to decide if it
>>>>>>> is
>>>>>>> worth it for them.  I imagine some people would still do it and
>>>>>>> either sacrifice the use of those plugins or they help to
>>>>>>> contribute
>>>>>>> to fix them to work the API more appropriately, thus giving back
>>>>>>> to
>>>>>>> the community in a constructive manner.
>>>>>>>
>>>>>>> The current problem is that some of the maven code is very nasty
>>>>>>> and
>>>>>>> some it isn't always easy to inject your own implementations
>>>>>>> into
>>>>>>> it.
>>>>>>>
>>>>>>> The way I see it, it is more about building a nice injectable
>>>>>>> architecture with really good clean API's, then power users can
>>>>>>> basically do whatever they want easily.   Therefore, you
>>>>>>> wouldn't
>>>>>>> be
>>>>>>> directly supporting this feature...but by creating a clean
>>>>>>> injectable architecture you would support without that intent
>>>>>>> anyway.
>>>>>>>
>>>>>>> This way, the maven team isn't supporting it per se, but rather
>>>>>>> the
>>>>>>> architecture supports the ability for someone to do it at their
>>>>>>> own
>>>>>>> risk.
>>>>>>>
>>>>>>>
>>>>>>> kind regards,
>>>>>>>
>>>>>>> Jason
>>>>>>>
>>>>>>>
>>>>>>> ________________________________________
>>>>>>> From: Stephen Connolly [stephen.alan.connolly@gmail.com]
>>>>>>> Sent: Saturday, September 05, 2009 5:45 AM
>>>>>>> To: Maven Developers List
>>>>>>> Cc: Maven Developers List
>>>>>>> Subject: Re: Re : Re : non-xml poms in 3.x
>>>>>>>
>>>>>>> personally, given the fun with rewriting XML at the moment, (see
>>>>>>> versions maven plugin) I would prefer to just have the current
>>>>>>> XML
>>>>>>> format. adding more formats makes some of the things that the
>>>>>>> versions
>>>>>>> maven current does a little harder to support.
>>>>>>>
>>>>>>> Sent from my [rhymes with myPod] ;-)
>>>>>>>
>>>>>>> On 5 Sep 2009, at 12:00, Julien HENRY <henryju@yahoo.fr>
wrote:
>>>>>>>
>>>>>>>> In the very specific case of groupId/artifactId/version pattern
>>>>>>>> which is currently very verbose I would tend to agree to
allow
>>>>>>>> shorter syntax using attributes instead of elements.
>>>>>>>>
>>>>>>>> <dependency groupId="" artifactId="" version="" classifier=""
>>>>>>>> scope=""/>
>>>>>>>>
>>>>>>>> <plugin groupId="" artifactId="" version="">
>>>>>>>> <configuration>
>>>>>>>> ...
>>>>>>>> </configuration>
>>>>>>>> </plugin>
>>>>>>>>
>>>>>>>> This is not what I consider a "big" change for endusers.
>>>>>>>>
>>>>>>>> Still my 2 cents.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Julien
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Message d'origine ----
>>>>>>>>> De : Jason Chaffee <jason.chaffee@zilliontv.tv>
>>>>>>>>> À : Maven Developers List <dev@maven.apache.org>
>>>>>>>>> Envoyé le : Samedi, 5 Septembre 2009, 1h00mn 02s
>>>>>>>>> Objet : RE: Re : non-xml poms in 3.x
>>>>>>>>>
>>>>>>>>> FYI, I know that in the past Resin supported both Elements
and
>>>>>>>>> attributes in
>>>>>>>>> it's config XML.  It was really neat.  If you preferred
one
>>>>>>>>> over
>>>>>>>>> the other, you
>>>>>>>>> could use it.  Don't know if it is still that way though.
>>>>>>>>>
>>>>>>>>> Jason
>>>>>>>>> ________________________________________
>>>>>>>>> From: Jason Chaffee [jason.chaffee@zilliontv.tv]
>>>>>>>>> Sent: Friday, September 04, 2009 3:27 PM
>>>>>>>>> To: Maven Developers List
>>>>>>>>> Subject: RE: Re : non-xml poms in 3.x
>>>>>>>>>
>>>>>>>>> I like the idea of having some things as attributes.
>>>>>>>>>
>>>>>>>>> See the following links on information on when to use
>>>>>>>>> attributes
>>>>>>>>> and when to use
>>>>>>>>> elements.
>>>>>>>>>
>>>>>>>>> http://www.ibm.com/developerworks/xml/library/x-eleatt.html
>>>>>>>>> http://nedbatchelder.com/blog/200412/
>>>>>>>>> elements_vs_attributes.html
>>>>>>>>> http://www.x12.org/x12org/comments/X12Reference_Model_For_XML_Design.pdf
>>>>>>>>>
>>>>>>>>> In particular, from the X12 Reference Model for XML Design:
>>>>>>>>>
>>>>>>>>> 7.2.5 Elements vs. Attributes
>>>>>>>>> Description: Often it is possible to model a data item
as a
>>>>>>>>> child
>>>>>>>>> element or an
>>>>>>>>> attribute.
>>>>>>>>>
>>>>>>>>> Benefits of Using Elements
>>>>>>>>>
>>>>>>>>> -They are more extensible because attributes can later
be
>>>>>>>>> added
>>>>>>>>> to
>>>>>>>>> them without
>>>>>>>>> affecting a processing application.
>>>>>>>>> -They can contain other elements. For example, if you
want to
>>>>>>>>> express a textual
>>>>>>>>> description using XHTML tags, this is not possible if
>>>>>>>>> description
>>>>>>>>> is an
>>>>>>>>> attribute.
>>>>>>>>> -They can be repeated. An element may only appear once
now,
>>>>>>>>> but
>>>>>>>>> later you may
>>>>>>>>> wish to extend it to appear multiple times.
>>>>>>>>> -You have more control over the rules of their appearance.
For
>>>>>>>>> example, you can
>>>>>>>>> say that a product can either have a number or a productCode
>>>>>>>>> child.
>>>>>>>>> This is not
>>>>>>>>> possible for attributes.
>>>>>>>>> -Their order is significant if specified as part of a
>>>>>>>>> sequence,
>>>>>>>>> while the order
>>>>>>>>> of attributes is not. Obviously, this is only an advantage
if
>>>>>>>>> you
>>>>>>>>> care about the
>>>>>>>>> order.
>>>>>>>>> -When the values are lengthy, elements tend to be more
>>>>>>>>> readable
>>>>>>>>> than attributes.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Disadvantages of Using Elements
>>>>>>>>>
>>>>>>>>> -Elements require start and end tags, so are therefore
more
>>>>>>>>> verbose. (NOTE: not
>>>>>>>>> all elements require a start and end tag — elements
can be
>>>>>>>>> declare
>>>>>>>>> d in a single
>>>>>>>>> line.)
>>>>>>>>>
>>>>>>>>> Benefits of Using Attributes
>>>>>>>>>
>>>>>>>>> -They are less verbose.
>>>>>>>>> -Attributes can be added to the instance by specifying
default
>>>>>>>>> values. Elements
>>>>>>>>> cannot (they must appear to receive a default value).
>>>>>>>>> -Attributes are atomic and cannot be extended and its
>>>>>>>>> existence
>>>>>>>>> should serve to
>>>>>>>>> remove any and all possible ambiguity of the element
it
>>>>>>>>> describes.
>>>>>>>>> They are
>>>>>>>>> “adjectives” to the element “noun”.
>>>>>>>>>
>>>>>>>>> Disadvantages of Using Attributes
>>>>>>>>>
>>>>>>>>> -Attributes may not be extended by adding children, whereas
a
>>>>>>>>> complex element
>>>>>>>>> may be extended by adding additional child elements or
>>>>>>>>> attributes.
>>>>>>>>> -If attributes are to be used in addition to elements
for
>>>>>>>>> conveying
>>>>>>>>> business
>>>>>>>>> data, rules are required for specifying when a specific
data
>>>>>>>>> item
>>>>>>>>> shall be an
>>>>>>>>> element or an attribute.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Jason
>>>>>>>>> ________________________________________
>>>>>>>>> From: paulus.benedictus@gmail.com
>>>>>>>>> [paulus.benedictus@gmail.com]
>>>>>>>>> On
>>>>>>>>> Behalf Of
>>>>>>>>> Paul Benedict [pbenedict@apache.org]
>>>>>>>>> Sent: Friday, September 04, 2009 3:05 PM
>>>>>>>>> To: Maven Developers List
>>>>>>>>> Subject: Re: Re : non-xml poms in 3.x
>>>>>>>>>
>>>>>>>>> Yes, the XML is verbose, and tooling helps but I think
most
>>>>>>>>> people
>>>>>>>>> write it
>>>>>>>>> by hand. The only evolutionary change I support is the
ability
>>>>>>>>> to
>>>>>>>>> specify
>>>>>>>>> simple nested elements as attributes.
>>>>>>>>>
>>>>>>>>> Paul
>>>>>>>>>
>>>>>>>>> On Fri, Sep 4, 2009 at 4:40 PM, Jason Chaffee wrote:
>>>>>>>>>
>>>>>>>>>> For what it is worth, I have heard many complaints
either
>>>>>>>>>> about
>>>>>>>>>> using XML
>>>>>>>>>> and/or about the current structure of the XML as
well.   I
>>>>>>>>>> have
>>>>>>>>>> heard this
>>>>>>>>>> from developers I have worked with and I have read
some blogs
>>>>>>>>>> about this
>>>>>>>>>> too.  I can't tell you where those blogs are now
because I
>>>>>>>>>> pretty
>>>>>>>>>> much
>>>>>>>>>> dismissed them as I like using XML myself.
>>>>>>>>>>
>>>>>>>>>> Jason
>>>>>>>>>> ________________________________________
>>>>>>>>>> From: Christian Edward Gruber
>>>>>>>>>> [christianedwardgruber@gmail.com]
>>>>>>>>>> Sent: Friday, September 04, 2009 2:29 PM
>>>>>>>>>> To: Maven Developers List
>>>>>>>>>> Subject: Re: Re : non-xml poms in 3.x
>>>>>>>>>>
>>>>>>>>>> Who said anything about a reasonable person? :) 
I don't have
>>>>>>>>>> such a
>>>>>>>>>> hatred - I'm quite used to it, but it has come up
in nearly
>>>>>>>>>> every
>>>>>>>>>> client in the last 3 years - not as a final or deal-breaking
>>>>>>>>>> barrier
>>>>>>>>>> to adoption, but a barrier nonetheless.
>>>>>>>>>>
>>>>>>>>>> I'm happy to support it - I just need a seam or hook
where I
>>>>>>>>>> can
>>>>>>>>>> provide something that pre-processes before the maven
run to
>>>>>>>>>> generate
>>>>>>>>>> the pom.xml.  Maven itself doesn't need to support
the
>>>>>>>>>> alternate
>>>>>>>>>> format at all.  If it could be something that was
auto-
>>>>>>>>>> detected as
>>>>>>>>>> well (or at worst, put into a settings.xml) then
that'd be
>>>>>>>>>> great.
>>>>>>>>>> Essentially I'm doing that now with the maven-yamlpom-
>>>>>>>>>> plugin...
>>>>>>>>>> it's
>>>>>>>>>> just that I have to do a separate run because it
modifies the
>>>>>>>>>> pom.xml,
>>>>>>>>>> and so maven fails on the first sync because the
pom was
>>>>>>>>>> modified.
>>>>>>>>>>
>>>>>>>>>> In a pinch, this can all be handled with shell scripts
>>>>>>>>>> wrapping
>>>>>>>>>> maven,
>>>>>>>>>> but I'd prefer to have a cleaner place to integrate.
>>>>>>>>>>
>>>>>>>>>> Christian.
>>>>>>>>>>
>>>>>>>>>> On Sep 4, 2009, at 5:12 PM, Jason van Zyl wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 2009-09-04, at 10:59 PM, Christian Edward
Gruber wrote:
>>>>>>>>>>>
>>>>>>>>>>>> So I agree that it is a valid concern, and
there needs to
>>>>>>>>>>>> be a
>>>>>>>>>>>> canonical format (which will probably be
XML) which all
>>>>>>>>>>>> artifacts
>>>>>>>>>>>> are saved as - but in my source tree, it
should be entirely
>>>>>>>>>>>> possible to have an alternate way to specify,
since often
>>>>>>>>>>>> I've
>>>>>>>>>>>> found that XML-hatred is a barrier to Maven
adoption in
>>>>>>>>>>>> some
>>>>>>>>>>>> firms.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I have not found this to be a concern. There's
lots of other
>>>>>>>>>>> things
>>>>>>>>>>> that are barrier but the XML has honestly never
come up in
>>>>>>>>>>> any
>>>>>>>>>>> conversations I've had.
>>>>>>>>>>>
>>>>>>>>>>>> You should always be able to get the pom.xml...
>>>>>>>>>>>> help:canonical-
>>>>>>>>>>>> pom
>>>>>>>>>>>> would be a decent way to quickly do it, and
artifacts
>>>>>>>>>>>> should
>>>>>>>>>>>> be
>>>>>>>>>>>> published that way - but a Project is an
object, and
>>>>>>>>>>>> alternate
>>>>>>>>>>>> serializations shouldn't be a problem.
>>>>>>>>>>>
>>>>>>>>>>> Therein lies the problem, the only real canonical
form is
>>>>>>>>>>> the
>>>>>>>>>>> object
>>>>>>>>>>> model. With 3 XML formats which one is the canonical
format?
>>>>>>>>>>> The
>>>>>>>>>>> first one?
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I would, also as an evangelist and implementor
of build
>>>>>>>>>>>> systems
>>>>>>>>>>>> in
>>>>>>>>>>>> companies, encourage that a company standardize
on a
>>>>>>>>>>>> format,
>>>>>>>>>>>> but
>>>>>>>>>>>> if
>>>>>>>>>>>> that company wants to use YAML, or some other
terser, more
>>>>>>>>>>>> human
>>>>>>>>>>>> readable format for the pom, then I'm good
with that.
>>>>>>>>>>>
>>>>>>>>>>> I'm not. Again this falls into my category of
"if you want
>>>>>>>>>>> it
>>>>>>>>>>> that
>>>>>>>>>>> way, you support it." A company can standardize
on whatever
>>>>>>>>>>> it
>>>>>>>>>>> wants, but I'm not going to hide the real cost
of that. We
>>>>>>>>>>> may
>>>>>>>>>>> ultimately decide it's not worth it having another
XML
>>>>>>>>>>> format.
>>>>>>>>>>> There
>>>>>>>>>>> are a lot more things in 3.0 that interest me
then another
>>>>>>>>>>> XML
>>>>>>>>>>> format.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I used to feel more like you, Brian, but
for the sheer
>>>>>>>>>>>> intensity
>>>>>>>>>>>> of
>>>>>>>>>>>> hatred of XML out there (as a format for
human-maintained
>>>>>>>>>>>> source).
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Again, I've not witnessed any XML hatred or that
being a
>>>>>>>>>>> justification by a reasonable person not to use
Maven.
>>>>>>>>>>>
>>>>>>>>>>>> The problem you're describing about one project
using one
>>>>>>>>>>>> and
>>>>>>>>>>>> another using a different one - that's no
different than
>>>>>>>>>>>> one
>>>>>>>>>>>> project deciding to use a different set of
integration test
>>>>>>>>>>>> plugins
>>>>>>>>>>>> (invoker vs. shitty) and confusing the noobs.
 The bottom
>>>>>>>>>>>> line
>>>>>>>>>>>> is
>>>>>>>>>>>> that you're not going to be able to constraint
people from
>>>>>>>>>>>> going
>>>>>>>>>>>> for the "new thing" and messing up the inexperienced,
so
>>>>>>>>>>>> providing
>>>>>>>>>>>> sane defaults with lots of room to customize
is the best
>>>>>>>>>>>> option,
>>>>>>>>>>>> in
>>>>>>>>>>>> my view.
>>>>>>>>>>>>
>>>>>>>>>>>> Christian.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Sep 4, 2009, at 4:25 PM, Brian Fox wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>> Just my 2 cents as a Maven evangelist
in a big private
>>>>>>>>>>>>>> company.
>>>>>>>>>>>>>> Even if
>>>>>>>>>>>>>> Maven is around for years now, basic
endusers just start
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> get
>>>>>>>>>>>>>> accustomed to pom.xml and Maven philosophy
(really!
>>>>>>>>>>>>>> people
>>>>>>>>>>>>>> are
>>>>>>>>>>>>>> far slowest to change than in OpenSource
project team).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please, please don't mess everything.
Small additions are
>>>>>>>>>>>>>> fine,
>>>>>>>>>>>>>> but I think a new format is a bad
idea even if it is
>>>>>>>>>>>>>> optional.
>>>>>>>>>>>>>> One of advantage of Maven is standardization
across all
>>>>>>>>>>>>>> our
>>>>>>>>>>>>>> projects. If there are several format
allowed, some
>>>>>>>>>>>>>> projects
>>>>>>>>>>>>>> will
>>>>>>>>>>>>>> start using new one when others are
still using the
>>>>>>>>>>>>>> former
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>> will lead to a total mess.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> That's my main concern as well to be
honest.
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> ---------------------------------------------------------------
>>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Jason
>>>>>>>>>>>
>>>>>>>>>>> ----------------------------------------------------------
>>>>>>>>>>> Jason van Zyl
>>>>>>>>>>> Founder,  Apache Maven
>>>>>>>>>>> http://twitter.com/jvanzyl
>>>>>>>>>>> http://twitter.com/SonatypeNexus
>>>>>>>>>>> http://twitter.com/SonatypeM2E
>>>>>>>>>>> ----------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>> ------------------------------------------------------------------
>>>>>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jason
>>>>>>
>>>>>> ----------------------------------------------------------
>>>>>> Jason van Zyl
>>>>>> Founder,  Apache Maven
>>>>>> http://twitter.com/jvanzyl
>>>>>> http://twitter.com/SonatypeNexus
>>>>>> http://twitter.com/SonatypeM2E
>>>>>> ----------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>>
>>>>
>>>> Christian Edward Gruber
>>>> e-mail: christianedwardgruber@gmail.com
>>>> weblog: http://www.geekinasuit.com/
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder,  Apache Maven
>>> http://twitter.com/jvanzyl
>>> http://twitter.com/SonatypeNexus
>>> http://twitter.com/SonatypeM2E
>>> ----------------------------------------------------------
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/SonatypeNexus
> http://twitter.com/SonatypeM2E
> ----------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> 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