Well I can see some point to that. There are scm tags in the POM where you can
download the source. In this case I like to think of this more like giving me
the files I would put on a website. On the site I would want the real jar,
javadocs, sources, and a real, compilable source code. The second file I have
been talking about is more like a changelog readme. What I want to do when I
make a release is just copy files out of target (or my Nexus instance) and
give them to my customer and not have to manually svn export and zip and such,
while still having them in my Nexus repository for easy download later or from
other Maven projects.
Jason
On 9/28/2011 5:01 PM, Thiessen, Todd (Todd) wrote:
Ahh yes. It isn't meant for software development. It is the source you can debug through.
I think of this as the "real" source. Your terminology threw me for a loop.
Software you development from is usually denoted as a trunk or branch that you
check out from source control. I find it unusual to download the source from a
maven repository, unpack it and start modifying it.
-----Original Message-----
From: Jason Winnebeck [mailto:[email protected]]
Sent: Wednesday, September 28, 2011 4:50 PM
To: Maven Users List
Subject: Re: Deployment of REAL source and single file artifacts
Well, you can't unpack that jar then run mvn, because there's no
pom.xml in
the root. I think there is a way to get the POM in there but it goes
into
META-INF. It also never seems to include files like README, COPYING,
NOTICE,
etc. The sources jar also doesn't have my layout with src/main/java
etc. You
can't compile it. You can't run Maven with it. It doesn't include
copyright or
license files or even Apache's own NOTICE files. You can't rebuild the
binary
with it (L/GPL compliance). You can't run the unit tests with it.
So in pretty much every way I can think of, it doesn't meet the
criteria of
proper source code. It's a source reference jar. Wonderfully
appropriate for
use as reference in your favorite IDE. Completely inappropriate for
software
development.
Actually when I saw Maven's repo I was very pleased because at first I
thought
it had solved the GPL issue like Debian did where you get a src-deb.
But it
didn't. The -sources.jar doesn't meet the requirements of the GPL to
distribute that. So technically it seems to me that the typical project
in
maven central repository is not compliant with licenses like L/GPL
because you
aren't given an opportunity to download source nor a written notice to
obtain
the source that is capable of producing the binary. In this sense Maven
totally missed a huge opportunity to assist people in actual, proper
L/GPL
compliance where you can use maven-dependency-plugin to include
dependency
source. Now it is not legitimately practical to deliver a self-
contained
program that a user can run using Maven alone.
Since I'm actually wanting to distribute source that I intend people to
open
and modify, I need an archive that has that. Anders's suggestion
achieved that
(based on example from Apache).
Jason
On 9/28/2011 4:35 PM, Thiessen, Todd (Todd) wrote:
It's not the sources? Then what is it? It's the actual source for
any release that I have ever done ;-). How do you define REAL source?
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
