You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-dev@incubator.apache.org by Gilles Scokart <GS...@isabel.eu> on 2007/07/30 07:06:00 UTC
Publishing ivy on maven repository
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.
- Is it a good practice to publish alpha (or beta) release on
the central maven repository?
Should we release our alpha-2 on a maven repository? Should we release
our new beta-1 release on a maven repo?
In that case, what should be our pom?
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.
WDYT?
Gilles
Gilles Scokart
E-mail : GScokart@isabel.eu
Tel : +32
Fax : +32
Isabel NV/S.A.
Keizerinlaan 13-15 Boulevard de l'Imperatrice
1000 Brussels - Belgium
RPR Bruxelles / RPM Brussel: BE 0455 530 509
www.isabel.eu www.zoomit.eu
ZOOMIT is a Registred Trademark of Isabel NV/S.A.
Disclaimer : www.isabel.eu/gps/en/disclaimer/mailing.php
Re: Publishing ivy on maven repository
Posted by Xavier Hanin <xa...@gmail.com>.
I'm +1 to publish Ivy to a maven repository, even without a stable API.
We can publish to a private repository first (eg
http://incubator.apache.org/ivy/repository), to ensure we get things clean
and usable. We could publish the alpha 2 release to this private repository,
then for the beta 1 see if we can publish it to the central or snapshot
repo. The work to do for this is create a maven pom as suggested by steve,
and automate the publication in our ant build. It may be a good opportunity
to create some Ivy tasks to ease that (ivy to pom conversion?). For the
packaging I would stick with one big fat jar, with all dependencies declared
as optional. We will do better later.
Xavier
On 7/30/07, Gilles Scokart <gs...@gmail.com> wrote:
>
> 2007/7/30, Steve Loughran <st...@apache.org>:
> >
> > 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
> >
>
> Personally, I thing it is too early to have little jars. I think it
> will only make sense when we will have defined our API.
>
> But maybe having a small jar with the ant task depending on the 'big
> fat' jar containing all the rest would be nice in a first step.
>
>
> --
> Gilles SCOKART
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://incubator.apache.org/ivy/
http://www.xoocode.org/
Re: Publishing ivy on maven repository
Posted by Gilles Scokart <gs...@gmail.com>.
2007/7/30, Steve Loughran <st...@apache.org>:
>
> 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
>
Personally, I thing it is too early to have little jars. I think it
will only make sense when we will have defined our API.
But maybe having a small jar with the ant task depending on the 'big
fat' jar containing all the rest would be nice in a first step.
--
Gilles SCOKART
Re: Publishing ivy on maven repository
Posted by Steve Loughran <st...@apache.org>.
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