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
