Hi, IMHO a sources are needed but I agree with jvz and see it more clear in a separate artifact type. Think that javadoc may be also needed and end up with all these in a binary jar is not a good idea.
The folks at mevenide only have to add a check so if the source file is present in the repository add it as source artifact. The same for a javadoc artifact. Regards Carlos Sanchez A Coru�a, Spain Oness Project http://oness.sourceforge.net > -----Original Message----- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: Monday, July 12, 2004 5:37 PM > To: Maven Users List > Subject: Re: maven test release > > On Mon, 2004-07-12 at 11:10, Dion Gillard wrote: > > > I'm not sure I see the issue. If you are suggesting it should be > > another 'artifact JAR', I can see how that would be good, with a > > standard naming convention. But I'm not sure why having a > 'mix bag' is > > an issue. > > Joe user downloads one JAR and finds it works somehow for > stepping through the source and then Joe user downloads > another JAR and find this doesn't work which will illicit all > sorts of questions about why this works in some cases and > doesn't in others. Multiplicity with respect to this, as it > is with all things attempted in Maven, is not a good thing. > > > > For releases, I think it would be cool to have the source > jar made > > > as well as part of the standard process. For snapshots I > don't know > > > if this is really worth it. > > > > Do you meant the one produced by the dist plugin? > > > > > How to make this easy for users? I think this falls in > the domain of > > > the IDE. For example, I don't think it would take much for the > > > Mevenide folks to add a snippet of code to look for a > source archive > > > artifact and pull it down if the user wishes. We should make the > > > source drops available but mixing sources with binaries I > think is a big no no. > > > > I can easily roll it back out of the jar plugin if you > like, but since > > Brett said 'commit away', I'm reluctant to do so. > > If putting the sources in the JAR is an option and that's > there now then I'm -1 on that becoming any sort of standard > of distributing sources. > > > For each L/GPL jar that gets distributed, the license says > the source > > must accompany the binaries. > > They don't have to be in the JAR, they have to be available. > > > I get the feeling ibiblio is illegally distributing jars like > > checkstyle because there is no source provided with the > binaries, and > > Maven simply downloads the jar. > > The sources have to be available and we do not repackage > anything and make a new distribution for which we would have > to provide the source. > But for most things like checkstyle the source is freely available: > > http://sourceforge.net/project/showfiles.php?group_id=29721 > > > Having source in the jar alleviates the need to do this for > those with > > that sort of license, similar to ensuring the license is in > META-INF. > > The source is available, this is not a problem and if any > project sees it as a problem, as I noted when Dalibor Topic > complained the last time, we can remove their artifacts from > ibiblio but I doubt any project would want that. > > Or you could just change the deploy plugin to push the source > archive up there too and then IDEs or users can pull down > what they like. > > > If the Maven team doesn't want this feature, I could simply > release it > > elsewhere if there's a need. > > Source archive available for every artifact: > > +1 > > Mixing in the sources with the standard JAR: > > -1 > > > -- > jvz. > > Jason van Zyl > [EMAIL PROTECTED] > http://maven.apache.org > > happiness is like a butterfly: the more you chase it, the > more it will elude you, but if you turn your attention to > other things, it will come and sit softly on your shoulder ... > > -- Thoreau > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
