I don't know if I've ever seen Maven work "flawlessly with ease". ;)
Dan Tran wrote:
I would suggest to add it via a profile activation at release:perform,
once it is proved to work flawlessly with ease. I am sure people will
not mind use it
-D
On Wed, Jun 10, 2009 at 8:18 AM, Paul Gier<[email protected]> wrote:
Within Red Hat it's a requirement that anything shipped with our products,
including thirdparty jars, is rebuilt from source. So that's part of my
reasoning behind wanting this. I realize that is not a requirement at most
organizations, but it still seems better to have it available.
The ideal solution IMO would be if the same jar/zip could be used for IDE
integration and would contain the full sources for rebuilding, but I don't
think that's possible.
We don't have to require that the full source zips are uploaded. Just
making it recommended and easy to do is enough IMO.
Brent Atkinson wrote:
For what it's worth, I agree with Dan.
I see the argument with change affecting SCM systems, but when you change
systems you're making a specific choice to break something where history
matters. If you're porting history, the identifier may change, but you
should still have the released code. If you're managing things
appropriately, you also have the binary dependencies. Bundling what amounts
to a source rpm (zip in this case) for each release feels like a lazy,
brute-force source management method. I suppose if you have the resources to
throw at it, it can save you some headaches. Requiring it seems a bit
strong, especially if the safety net serves as a rationalization for quickly
migrating to the SCM du jour. That decision should still carry a
considerable burden with it.
Maybe I'm missing the point?
Brent
Dan Tran <[email protected]> 6/9/2009 6:43 PM >>>
Is this really necessary? For me as long as I have the source [1],
that is all i want.
http://repo2.maven.org/maven2/org/codehaus/mojo/build-helper-maven-plugin/1.3/
-D
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
