Concerns About Pushing Clojure 1.0.0 to Maven Central Repo?
Stefan Hübner
Since Clojure now has a stable 1.0.0 I would like to take a step
forward and push it to Maven's Central Repo at http://repo1.maven.org/maven2/.
This would allow people using Maven to integrate Clojure more easily,
since no 3rd party repo wouldn't be involved anymore.
I'm going to follow these guidelines:
http://maven.apache.org/guides/mini/guide-central-repository-upload.html.
But before I'll proceed, I would like to make sure, that there a no
concerns about doing so. If anyone is concerned about pushing Clojure
into Central, please give me some feedback.
If you're OK with the idea, I will alter the distributed POM slightly
to meet the guidelines. The modification is about the missing scm-
part. POM and clojure-1.0.0.jar would then go into the upload bundle
and would be submitted to the Upload Team. Should I add clojure-1.0.0-
sources.jar as well?
The modified POM will look like this:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http//www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.clojure</groupId>
<artifactId>clojure-lang</artifactId>
<name>clojure-lang</name>
<version>1.0.0</version>
<packaging>jar</packaging>
<url>http://clojure.org/</url>
<description>Clojure core environment and runtime library.</
description>
<licenses>
<license>
<name>Eclipse Public License 1.0</name>
<url>http://opensource.org/licenses/eclipse-1.0.php</url>
<distribution>repo</distribution>
</license>
</licenses>
<scm>
<connection>scm:svn:http://clojure.googlecode.com/svn/tags/1.0/</
connection>
<url>http://code.google.com/p/clojure/source/browse/</url>
</scm>
</project>
Are there any suggestions or concerns about the bundled files or the
POM (or the idea to push Clojure to Central altogether)?
Thanks for any feedback,
-Stefan
Josh Daghlian
it's especially annoying when one has to set up sources jars manually
(in intellij or whatever) by manually downloading the source and
depositing it somewhere safe on the filesystem when maven could be
doing it for me.
Thanks!
--josh
On May 6, 1:09 pm, Stefan Hübner <sthueb...@googlemail.com> wrote:
> Hi all,
>
> Since Clojure now has a stable 1.0.0 I would like to take a step
> since no 3rd party repo wouldn't be involved anymore.
>
> I'm going to follow these guidelines:http://maven.apache.org/guides/mini/guide-central-repository-upload.html.
> But before I'll proceed, I would like to make sure, that there a no
> concerns about doing so. If anyone is concerned about pushing Clojure
> into Central, please give me some feedback.
>
> If you're OK with the idea, I will alter the distributed POM slightly
> to meet the guidelines. The modification is about the missing scm-
> part. POM and clojure-1.0.0.jar would then go into the upload bundle
> and would be submitted to the Upload Team. Should I add clojure-1.0.0-
> sources.jar as well?
>
> The modified POM will look like this:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <project xmlns="http://maven.apache.org/POM/4.0.0"
> xmlns:xsi="http//www.w3.org/2001/XMLSchema-instance"
Laurent PETIT
clojureXX.jar
clojure-slimXX.jar
clojure-sourcesXX.jar
2009/5/7 Josh Daghlian <dagh...@gmail.com>:
Stefan Hübner
> I also think it makes sense to deposit the whole "battery" :
> clojureXX.jar
> clojure-slimXX.jar
OK, I would bundle clojure-slim.jar too. I'm not familiar with it, though
curious. Would you enlighten me by throwing some light on it's purpose?
> clojure-sourcesXX.jar
Will be bundled.
-Stefan
Laurent PETIT
> Laurent PETIT <lauren...@gmail.com> writes:
>
>> I also think it makes sense to deposit the whole "battery" :
>> clojureXX.jar
>> clojure-slimXX.jar
>
> OK, I would bundle clojure-slim.jar too. I'm not familiar with it, though
> curious. Would you enlighten me by throwing some light on it's purpose?
files (in folder src/jvm/ )
clojure-slimXX.jar contains compiled java files from src/jvm/ + clj
files from src/clj/
clojureXX.jar contains compiled java files from src/jvm/ + clj files
from src/clj/ + compiled into java classes cjl files from src/clj/
clojureXX.jar has a better startup time since clj files are already
compiled into bytecode into classes files (via AOT - Ahead Of Time -
clojure files compilation)
clojure-slimXX.jar is much smaller than clojureXX.jar. And the clj
files will be compiled into bytecode in memory "Just in Time"
Certainly both serve different needs for different people.
Regards,
--
Laurent
Stefan Hübner
I would bundle clojure-slim.jar as a "classified" clojure, like Maven
calls it. So the final filename would be "clojure-lang-1.0.0-slim.jar".
To use this one instead of clojure-lang-1.0.0.jar, the following
dependency needs to be declared:
<dependency>
<groupId>org.clojure</groupId>
<artifactId>clojure-lang</artifactId>
<version>1.0.0</version>
<classifier>slim</classifier>
</dependency>
-Stefan
Laurent PETIT
One question, though: I see that you want to name the artifact
"clojure-lang" and not just "clojure".
Why not just "clojure" as is the case for the ant build script ?
I guess this could just confuse people ?
2009/5/7 Stefan Hübner <sthu...@googlemail.com>:
Stefan Hübner
> Seems fine to me.
>
> One question, though: I see that you want to name the artifact
> "clojure-lang" and not just "clojure".
> Why not just "clojure" as is the case for the ant build script ?
>
> I guess this could just confuse people ?
Very good point! That's exactly the kind of feedback I was hoping to
get. Pushing a library to Maven Central isn't easy to rewind, if it's
possible at all. So I want to make sure beforehand, that the right thing
is going to get there.
So, here's my explanation, and I hope it is reasonable:
I just used the artifactId which is defined in the pom.xml
shipped with Clojure since r502 (2007-10-30). Why "clojure-lang" was
chosen in favour of just "clojure" confused me too, so I can not give a
good explanation. Maybe Rich or the original contributor can?
But, since Clojure has shipped this artifactId for 18 months now, it has
materialized in many people's repo like that, I guess. In fact, the
official 1.0 distribution "clojure-1.0.0.zip" has been shipped with this
pom.xml. It seems a matter of fact, that in the maven world Clojure
sails under the "clojure-lang" flag since day zero.
So I refused to change that quasi-standard, as I don't want to confuse
other people, who got used to "clojure-lang" in their maven world.
What shall we do then?
-Stefan
Laurent PETIT
You're right, so from the beginning the ant script creates
"clojure..." while the maven script creates "clojure-lang...".
Well, I thought that since the official build script is the ant one,
the pom.xml should be adapted. In either cases, people will have to
change things ...
I guess only Rich can make the choice: statu quo, clojure (breaks
maven artifact id), clojure-lang (breaks build.xml).
--
Laurent
J. McConnell
> maven artifact id), clojure-lang (breaks build.xml).
Not that I have a strong stake in this, but I'd vote for going with
"clojure" and getting it right for 1.0.
- J.
Stefan Hübner
> You're right, so from the beginning the ant script creates
> "clojure..." while the maven script creates "clojure-lang...".
To be precise here, there's no such maven script that creates
"clojure-lang", neither does Maven do anything during Clojure's build
process. The pom.xml is created by Ant too.
> Well, I thought that since the official build script is the ant one,
> the pom.xml should be adapted. In either cases, people will have to
> change things ...
>
> I guess only Rich can make the choice: statu quo, clojure (breaks
> maven artifact id), clojure-lang (breaks build.xml).
I second your notion. I guess Howard Lewis Ship ought to get involved
here too, since he maintains the continuous builds and seems to have his
own build scripts, as long as I'm right. Are they monitoring this
thread?
-Stefan
Laurent PETIT
>
> Laurent PETIT <lauren...@gmail.com> writes:
>
>> You're right, so from the beginning the ant script creates
>> "clojure..." while the maven script creates "clojure-lang...".
>
> To be precise here, there's no such maven script that creates
> "clojure-lang", neither does Maven do anything during Clojure's build
> process. The pom.xml is created by Ant too.
I know(*) :-), but it's a recent addition. The name "clojure-lang" was
there before ant creating the pom from pom-template, and this
artifactId name was not even closely reviewed during the process.
>
>> Well, I thought that since the official build script is the ant one,
>> the pom.xml should be adapted. In either cases, people will have to
>> change things ...
>>
>> I guess only Rich can make the choice: statu quo, clojure (breaks
>> maven artifact id), clojure-lang (breaks build.xml).
>
> I second your notion. I guess Howard Lewis Ship ought to get involved
> here too, since he maintains the continuous builds and seems to have his
> own build scripts, as long as I'm right. Are they monitoring this
> thread?
I think so.
>
> -Stefan
(*) I did the patch that made pom.xml generated from build.xml
Christian Vest Hansen
repo than after. When people are going to change their pom from some
odd snapshot to 1.0 anyway, then this is probably a good time to sneak
this artifactId change in too, no?
>
> - J.
>
> >
>
--
Venlig hilsen / Kind regards,
Christian Vest Hansen.
Stefan Hübner
> On Thu, May 7, 2009 at 4:47 PM, J. McConnell <jdo...@gmail.com> wrote:
>>
>>> I guess only Rich can make the choice: statu quo, clojure (breaks
>>> maven artifact id), clojure-lang (breaks build.xml).
>>
>> Not that I have a strong stake in this, but I'd vote for going with
>> "clojure" and getting it right for 1.0.
>
> Right. It's easier to change this pom before it goes into the public
> repo than after. When people are going to change their pom from some
> odd snapshot to 1.0 anyway, then this is probably a good time to sneak
> this artifactId change in too, no?
I agree with your position. So, along with uploading the bundle to
Central, I'll provide a patch to reflect pom changes in SVN.
I'm going to push the bundle forward during the weekend.
-Stefan
Stefan Hübner
> I also think it makes sense to deposit the whole "battery" :
> clojureXX.jar
> clojure-slimXX.jar
> clojure-sourcesXX.jar
Since clojure-slim is not bundled in the distributed ZIP for 1.0.0, I'm
going the build all three libraries from SVN tag "1.0" (r1365).
I've figured, though, that the resulting libraries contain class files,
which are of different size than those found in the distributed
clojure-1.0.0.jar. How can this actually happen? Is this problematic?
My build environment was Debian squeeze, SUN J2SE 1.6.0_13, Ant 1.7.0,
OS character encoding UTF-8.
Eventhough I do not have an explanation for the different build results,
building from a fresh /svn/tags/1.0 should be OK, shouldn't it?
-Stefan
Laurent PETIT
> I also think it makes sense to deposit the whole "battery" :Since clojure-slim is not bundled in the distributed ZIP for 1.0.0, I'm
> clojureXX.jar
> clojure-slimXX.jar
> clojure-sourcesXX.jar
going the build all three libraries from SVN tag "1.0" (r1365).
svn tag 1.0 is correct, it's a copy of branch 1.0 in revision 1362 .
I've figured, though, that the resulting libraries contain class files,
which are of different size than those found in the distributed
clojure-1.0.0.jar. How can this actually happen? Is this problematic?
My build environment was Debian squeeze, SUN J2SE 1.6.0_13, Ant 1.7.0,
OS character encoding UTF-8.
note that clojure must be compatible with JDK 1.5, so if you compile with 1.6, maybe you should verify the compatibility mode (not sure if what I write here makes sense, I'm not a specialist in javac retrocompatibility concerns).
Howard Lewis Ship
same group.
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
Stefan Hübner
> clojure-lang because there will be a clojure-contrib artifact for the
> same group.
group would render "org.clojure:clojure" a bad choice as
groupId:artifactId for clojure itself. Does your suggestion follow a
particular recommendation or policy?
-Stefan
Stefan Hübner
> note that clojure must be compatible with JDK 1.5, so if you compile with
> 1.6, maybe you should verify the compatibility mode (not sure if what I
> write here makes sense, I'm not a specialist in javac retrocompatibility
> concerns).
Laurent PETIT
Yes, then you would be certain of the target platform.
Compiling with javac -target=1.5 should also work, though.
Laurent PETIT
Hum... nevermind, -target=1.5 is already there in build.xml ...
Phil Hagelberg
> clojure-lang because there will be a clojure-contrib artifact for the
> same group.
And this is ... a bad thing? I'm lost.
-Phil
Daniel E. Renfer
Good, at least I'm not the only one.
Why can't we have both clojure and clojure-contrib as Id's?
Daniel E. Renfer
Stefan Hübner
really interested in all decisions regarding the Maven bundle to be as
transparent as possible. Since people will ask why the artifact has
been given a certain ID, I hope, this thread will document those
decisions for future reference. Thus, Howard's (and Rich's too)
opinion and explanation is be highly appreciated.
So uploading the bundle is going to be deferred for a couple of days.
-Stefan
Daniel Jomphe
> > On 8 Mai, 01:39, Laurent PETIT <laurent.pe...@gmail.com> wrote:
> > > note that clojure must be compatible with JDK 1.5, so if you compile with
> > > 1.6, maybe you should verify the compatibility mode (not sure if what I
> > > write here makes sense, I'm not a specialist in javac retrocompatibility
> > > concerns).
to produce 100% compatible bytecode is to compile using the proper jvm
version. They explicitly mentioned 1.6 compiling with a target of 1.4
or 1.5 wouldn't produce 100% compatible byte code for these platforms.
Sadly, I don't remember the explanation, though. :\ In any case,
that's good to keep in our minds for future work.
ataggart
whatever the choice of naming, the artifact and module names should
parallel. The reason for this request is that Ivy can resolve
dependencies in maven by creating URLs from a pattern. For example:
<dependency org="org.clojure" name="clojure" rev="1.0.0" />
pulls from org/clojure/clojure/1.0.0/clojure-1.0.0.jar
<dependency org="org.clojure" name="clojure-lang" rev="1.0.0" />
pulls from org/clojure/clojure-lang/1.0.0/clojure-lang-1.0.0.jar
Both fine, and there are a few (thankfully, very few) Maven artifacts
which break this pattern. But please do not do something that results
in a URL like:
org/clojure/clojure-lang/1.0.0/clojure-1.0.0.jar
As for clojure-contrib, <dependency org="org.clojure" name="clojure-
contrib" rev="1.0.0" /> pulling from org/clojure/clojure-contrib/1.0.0/
clojure-contrib-1.0.0.jar looks fine to me.
Howard Lewis Ship
just "clojure". It's do differentiate Rich's framework,
"clojure-lang", from the Contrib librarys ("clojure-contrib") even
though they are both in the same Maven group.
Laurent PETIT
It seems that it's really a matter of convention, I don't see any technical problem of having a groupId of org.clojure and an artifactId of clojure.
Please let me try to summarize this never ending discussion:
Currently the master build script is ant's build.xml.
It generates clojure.jar (*)
Currently the maven pom.xml defines
a groupId : org.clojure
an artifactId : clojure-lang
* The groupId is ok since the website site of clojure is indeed clojure.org
* The artifactId is ko since it implies the creation of jars such as clojure-lang.jar (*)
Changing one or the other is just a matter of a one liner (or so) patch to make both compliant and save lots of "brain overhead" for all newcomers (and also members of the list if the newcomers come and ask the same question again and again).
Rich, please have the final word:
* is it ok to live with different jar names
* if no, do we change pom.xml to name the artifactId clojure instead of clojure-lang, or do we change the build.xml to generate clojure-lang.jar instead of clojure.jar
(*) and derivatives with version numbers, and classifiers for slim and source
Stefan Hübner
ataggart <alex.t...@gmail.com> writes:
> I use Maven indirectly via Ivy, so I just wanted to request that,
> whatever the choice of naming, the artifact and module names should
> parallel. The reason for this request is that Ivy can resolve
> dependencies in maven by creating URLs from a pattern. For example:
>
> <dependency org="org.clojure" name="clojure" rev="1.0.0" />
> pulls from org/clojure/clojure/1.0.0/clojure-1.0.0.jar
>
> <dependency org="org.clojure" name="clojure-lang" rev="1.0.0" />
> pulls from org/clojure/clojure-lang/1.0.0/clojure-lang-1.0.0.jar
That's exactly how Maven does it too. So there will be no broken patterns.
> Both fine, and there are a few (thankfully, very few) Maven artifacts
> which break this pattern. But please do not do something that results
> in a URL like:
>
> org/clojure/clojure-lang/1.0.0/clojure-1.0.0.jar
I haven't heard of any such artifact yet. Can you name one (just curious)?
> As for clojure-contrib, <dependency org="org.clojure" name="clojure-
> contrib" rev="1.0.0" /> pulling from org/clojure/clojure-contrib/1.0.0/
> clojure-contrib-1.0.0.jar looks fine to me.
For the moment, that's out of scope for me. But true, the pattern must
follow the same rules.
-Stefan
Stefan Hübner
thanks for the summary! I'm looking forward to the decision and hope, we
can move forward soon.
Daniel Renfer
>
> It's the answer to why the main artifact is called "clojure-lang" not
> just "clojure". It's do differentiate Rich's framework,
> "clojure-lang", from the Contrib librarys ("clojure-contrib") even
> though they are both in the same Maven group.
Please excuse me, as I am just now trying to get used to Maven, so I'm
still learning all the conventions.
Wouldn't the fact that their artifact id's are different clearly
differentiate the two? That's certainly how it works everywhere else.
Is there some sort of Maven rule that I just don't know about that
having an artifact id that is a derivative of another id in the same
group implies some sort of inheritance or something?
If not, we should just get it changed to 'clojure', so it's in line
with the project name, and the same name for the jars as the official
ant script.
Unless you have some reason why it's bad.
Daniel E. Renfer
Stefan Hübner
> On Tue, May 12, 2009 at 4:51 PM, Howard Lewis Ship <hls...@gmail.com> wrote:
>>
>> It's the answer to why the main artifact is called "clojure-lang" not
>> just "clojure". It's do differentiate Rich's framework,
>> "clojure-lang", from the Contrib librarys ("clojure-contrib") even
>> though they are both in the same Maven group.
>
> Please excuse me, as I am just now trying to get used to Maven, so I'm
> still learning all the conventions.
>
> Wouldn't the fact that their artifact id's are different clearly
> differentiate the two?
absolutely.
> That's certainly how it works everywhere else. Is there some sort of
> Maven rule that I just don't know about that having an artifact id
> that is a derivative of another id in the same group implies some sort
> of inheritance or something?
No, there is noch such rule. In fact, there isn't much magic behind
Maven's groupId and artifactId, really. It's just a matter of taste how
you name (by which artifactId is meant) your artifacts within a
group. Their artifactIds are directly reflected in their filenames.
If you wanted to place many artifacts within the same group, though, a
artifactId-nomenclatur would help people to find what they were looking
for. But it's completely up to you to come up with such a convention and
communicate it to the users (in one or another way).
-Stefan
Rich Hickey
> Hello,
>
> It seems that it's really a matter of convention, I don't see any technical
> problem of having a groupId of org.clojure and an artifactId of clojure.
>
> Please let me try to summarize this never ending discussion:
>
> Currently the master build script is ant's build.xml.
> It generates clojure.jar (*)
>
> Currently the maven pom.xml defines
> a groupId : org.clojure
> an artifactId : clojure-lang
>
> * The groupId is ok since the website site of clojure is indeed clojure.org
>
> * The artifactId is ko since it implies the creation of jars such as
> clojure-lang.jar (*)
>
> Changing one or the other is just a matter of a one liner (or so) patch to
> make both compliant and save lots of "brain overhead" for all newcomers (and
> also members of the list if the newcomers come and ask the same question
> again and again).
>
> Rich, please have the final word:
> * is it ok to live with different jar names
> * if no, do we change pom.xml to name the artifactId clojure instead of
> clojure-lang, or do we change the build.xml to generate clojure-lang.jar
> instead of clojure.jar
>
be called clojure. I don't want to change build.xml.
Rich
Stefan Hübner
-Stefan
Stefan Hübner
http://jira.codehaus.org/browse/MAVENUPLOAD-2464. Processing the request
might take a couple of days.
Once the bundle is uploaded to Central, one of the following two
snippets can be used to declare a dependency to Clojure:
<!-- Clojure with precompiled Lisp sources -->
<dependency>
<groupId>org.clojure</groupId>
<artifactId>clojure</artifactId>
<version>1.0.0</version>
</dependency>
<!-- Clojure without precompiled Lisp sources -->
<dependency>
<groupId>org.clojure</groupId>
<artifactId>clojure</artifactId>
<version>1.0.0</version>
<classifier>slim</classifier>
</dependency>
I'll submit patches to reflect the changed POM.
Thank you all for your support!
Stefan Hübner
Christian Vest Hansen
>
> I've submitted the Maven bundle for Clojure 1.0.0 to
> http://jira.codehaus.org/browse/MAVENUPLOAD-2464. Processing the request
> might take a couple of days.
long term solution, I think.
>
> Once the bundle is uploaded to Central, one of the following two
> snippets can be used to declare a dependency to Clojure:
>
> <!-- Clojure with precompiled Lisp sources -->
> <dependency>
> <groupId>org.clojure</groupId>
> <artifactId>clojure</artifactId>
> <version>1.0.0</version>
> </dependency>
>
> <!-- Clojure without precompiled Lisp sources -->
> <dependency>
> <groupId>org.clojure</groupId>
> <artifactId>clojure</artifactId>
> <version>1.0.0</version>
> <classifier>slim</classifier>
> </dependency>
>
> I'll submit patches to reflect the changed POM.
>
> Thank you all for your support!
> Stefan Hübner
>
>
> >
>
dysinger
have an (unspoken) consensus with Howard's POM work.
However, I would rather clojure proper just be named
"org.clojure:clojure" in maven/ivy-land myself and I have heard that
from quite a few others.
On May 10, 1:17 pm, d...@kronkltd.net (Daniel E. Renfer) wrote:
Stefan Hübner
http://jira.codehaus.org/browse/MAVENUPLOAD-2464, promotes Clojure as
"org.clojure:clojure:1.0.0". It hasn't received any atention from the
Upload team yet, but I do hope it gets uploaded within the next
weeks. Maybe voting could speed it up...
Paul Stadig
Thanks for the work everyone. I would love to see Clojure get into the Maven repo.
Paul
Stefan Hübner
> On Mon, May 18, 2009 at 8:59 AM, Stefan Hübner <sthu...@googlemail.com> wrote:
>>
>> I've submitted the Maven bundle for Clojure 1.0.0 to
>> http://jira.codehaus.org/browse/MAVENUPLOAD-2464. Processing the request
>> might take a couple of days.
>
> The upload guide says four weeks. Repository synchronization is the
> long term solution, I think.
Thats probably true. If someone from the core team/contributors has the
resources to set this up, that would be cool. It would speed up
promotion to Maven Central alot (fully automatic) - for future releases.