Gilles Scokart wrote:
I just realized a few days ago that ivy is not published on a maven
repository. Shouldn't we?
I know we don't really have a published API. But is it a good reason to
not publish the ivy library on a repository?
What I don't know is:
- Are allowed to do it as an incubating project? I think yes,
but I'm not sure.
I''ve emailed repository@ to see what the answer is. I think you may be
encouraged to stick it on on the snapshots repository.
- Is it a good practice to publish alpha (or beta) release on
the central maven repository?
For stuff you update on a daily/weekly basis, it is not ideal, but for
things you intend to last around, go for it, especially the beta.
With SmartFrog I'm just running a private repository at
http://smartfrog.sourceforge.net/repository; getting the whole pom
creation and artifact upload automated with our fortnightly releases.
once we come out of beta I'll put the live things up.
Should we release our alpha-2 on a maven repository? Should we release
our new beta-1 release on a maven repo?
+1, to the beta, 0 to the alpha.
In that case, what should be our pom?
0. Include the schema and stick things in the right place for an M2 pom.
Let's be a good citizen
1. keep its dependencies minimal. Its not to build the thing, only let
people use it.
2. I like to include (as a comment) some metadata about who wrote the
file, when, etc. We do this in the build by expanding a property in a
comment when creating the POM; lets me stick in whatever comments I want.
Here's the kind of POM I create
http://smartfrog.sourceforge.net/repository/org/smartfrog/sf-junit/3.11.005beta/sf-junit-3.11.005beta.pom
And here's the template I build it from:
http://smartfrog.svn.sourceforge.net/viewvc/smartfrog/trunk/core/components/junit/project-template.pom?view=markup
And what packaging should we use? I mean, should we build different
jars than the one we have now. Indeed the decomposition that we have
now is guided by the idea to have a single jar in order to make it
easier to manipulate it. But on a repository, the goal should be to
have to allow the user to get only what he need.
Three options
-a big fat jar with all the optional dependencies declared as mandatory
-a big fat jar with no optional dependencies
-lots of little jars with the optional dependencies pulled in.
You can also create a super bundle that pulls in the little JARs
steve
