You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2007/01/02 16:51:33 UTC
Shipping fat jar?
I am considering whether we should stop shipping the "fat"
cayenne.jar in 3.0 (would've been called cayenne-server-deps.jar
according to the new naming convention). The original motivation for
it goes back to the days when full CLASSPATH had to be specified when
running "javac" and "java" from command line. So it saved quite a bit
of typing. With Ant, Eclipse and war format this seems obsolete.
Instead I thought we might include a minimal set of runtime
dependencies in the "lib/third-party" folder.
Anybody thinks it is a bad idea to get rid of the fat jar?
Andrus
Re: Shipping fat jar?
Posted by Tore Halset <ha...@pvv.ntnu.no>.
Hello.
I have not moved to maven, but stopped to use the fat cayenne.jar as
I had some conflicting jar-files. I guess the fat jar is good for
quick-start for simple projects. Sooner or later most people will
probably want to have control over this in the project.
I do not care if we keep it or drop it.
- Tore.
On Jan 2, 2007, at 16:51, Andrus Adamchik wrote:
> I am considering whether we should stop shipping the "fat"
> cayenne.jar in 3.0 (would've been called cayenne-server-deps.jar
> according to the new naming convention). The original motivation
> for it goes back to the days when full CLASSPATH had to be
> specified when running "javac" and "java" from command line. So it
> saved quite a bit of typing. With Ant, Eclipse and war format this
> seems obsolete. Instead I thought we might include a minimal set of
> runtime dependencies in the "lib/third-party" folder.
>
> Anybody thinks it is a bad idea to get rid of the fat jar?
Re: Shipping fat jar?
Posted by Michael Gentry <bl...@gmail.com>.
I'm currently only using the fat jar for development and for
deployment for pre-3.0. If it makes sense for 3.0 to abandon it, I'd
survive. It is just much simpler (OK, lazier) to only have one jar,
but sometimes you need finer-grained control.
/dev/mrg
On 1/2/07, Andrus Adamchik <an...@objectstyle.org> wrote:
> I am considering whether we should stop shipping the "fat"
> cayenne.jar in 3.0 (would've been called cayenne-server-deps.jar
> according to the new naming convention). The original motivation for
> it goes back to the days when full CLASSPATH had to be specified when
> running "javac" and "java" from command line. So it saved quite a bit
> of typing. With Ant, Eclipse and war format this seems obsolete.
> Instead I thought we might include a minimal set of runtime
> dependencies in the "lib/third-party" folder.
>
> Anybody thinks it is a bad idea to get rid of the fat jar?
>
> Andrus
>
Re: Shipping fat jar?
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Jan 4, 2007, at 12:23 AM, Aristedes Maniatis wrote:
> On 04/01/2007, at 5:21 AM, Andrus Adamchik wrote:
>
>> That's true. I am trying to find an equally usable solution. So
>> far I can think of a "lib/third-party" folder that I mentioned
>> (and put into the new assembly descriptor).
>
> How about a very low tech approach. Create a file as part of the
> deployment (or a web page for that matter), which lists every
> dependency, the appropriate version (or range of versions), and the
> URL of the place to get the jar. We do that in our own project so
> that we can easily track what we are using and where we got it from.
In fact we do have this in place since the old days:
http://cwiki.apache.org/CAYDOC/jar-files-and-dependencies.html
Andrus
Re: Shipping fat jar?
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Jan 4, 2007, at 12:52 AM, Craig L Russell wrote:
>> How about a very low tech approach. Create a file as part of the
>> deployment (or a web page for that matter), which lists every
>> dependency, the appropriate version (or range of versions), and
>> the URL of the place to get the jar. We do that in our own project
>> so that we can easily track what we are using and where we got it
>> from.
>
> Doesn't the cayenne maven pom do this?
Here is a problem with that - Cayenne POM specifies lots of
dependencies that 99.9% of users will never need, but they are needed
to compile Cayenne (e.g. JGroups for clustering). So the "fat" jar
was a subset of compile dependencies that included only things that
are absolutely needed to run Cayenne (with the rest of them mentioned
in specific documentation). In fact "third-party" library directory
is now built from POM, but we have to do manual filtering :-/
<dependencySet>
<outputDirectory>lib/third-party</outputDirectory>
<!-- Include only a minimal set of dependencies to run cayenne-
server -->
<includes>
<include>asm:asm</include>
<include>asm:asm-commons</include>
<include>com.caucho:hessian</include>
<include>commons-collections:commons-collections</include>
<include>commons-lang:commons-lang</include>
<include>commons-logging:commons-logging</include>
<include>org.objectstyle.ashwood:ashwood</include>
<include>velocity:velocity</include>
</includes>
</dependencySet>
Andrus
Re: Shipping fat jar?
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Kevin,
I have no issues with having both fat and skinny jars, and multiple
ways to configure both fat and skinny jars.
I do suggest that if the identical information is in two places (the
pom and the easier to find/read place) there is the opportunity for
them to get out of sync.
I don't know if anyone has ever done so, but perhaps a simple xsl
script could scan the pom and extract just the info you're looking
for. Myself, I found that the pom was easy enough to scan by eye to
find the dependencies...[assuming it's a maven 1 pom that includes
all recursive dependencies, unlike maven 2]
Craig
On Jan 3, 2007, at 5:36 PM, Kevin Menard wrote:
>>> How about a very low tech approach. Create a file as part of the
>>> deployment (or a web page for that matter), which lists every
>>> dependency, the appropriate version (or range of versions), and the
>>> URL of the place to get the jar. We do that in our own
>> project so that
>>> we can easily track what we are using and where we got it from.
>>
>> Doesn't the cayenne maven pom do this?
>
> It does . . . providing you're familiar with maven and know what
> you're
> looking for. Before I started using maven, I had no clue that this
> was
> the case.
>
> So, +1 for making it easier to find/read.
>
> Even still, as a new user, I really don't want to be bothered with
> chasing dependencies. For most smaller apps, I still use the fat JAR
> just because it's very simple. Granted, the other approach isn't
> difficult, per se . . .
>
> --
> Kevin
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
RE: Shipping fat jar?
Posted by Kevin Menard <km...@servprise.com>.
> > How about a very low tech approach. Create a file as part of the
> > deployment (or a web page for that matter), which lists every
> > dependency, the appropriate version (or range of versions), and the
> > URL of the place to get the jar. We do that in our own
> project so that
> > we can easily track what we are using and where we got it from.
>
> Doesn't the cayenne maven pom do this?
It does . . . providing you're familiar with maven and know what you're
looking for. Before I started using maven, I had no clue that this was
the case.
So, +1 for making it easier to find/read.
Even still, as a new user, I really don't want to be bothered with
chasing dependencies. For most smaller apps, I still use the fat JAR
just because it's very simple. Granted, the other approach isn't
difficult, per se . . .
--
Kevin
Re: Shipping fat jar?
Posted by Craig L Russell <Cr...@Sun.COM>.
On Jan 3, 2007, at 2:23 PM, Aristedes Maniatis wrote:
>
> On 04/01/2007, at 5:21 AM, Andrus Adamchik wrote:
>
>> That's true. I am trying to find an equally usable solution. So
>> far I can think of a "lib/third-party" folder that I mentioned
>> (and put into the new assembly descriptor).
>
> How about a very low tech approach. Create a file as part of the
> deployment (or a web page for that matter), which lists every
> dependency, the appropriate version (or range of versions), and the
> URL of the place to get the jar. We do that in our own project so
> that we can easily track what we are using and where we got it from.
Doesn't the cayenne maven pom do this?
Craig
>
> When Cayenne moved to skinny jars the way I figured out what
> dependencies it needed was to keep running it, reading the
> exception and then installing that jar. I guessed that the most
> recent version of everything was the best thing to use, and they
> worked fine, but it would be nice to know exactly what versions of
> dependencies Cayenne is being tested with without reading the maven
> xml files.
>
> Ari Maniatis
>
>
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001 fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Shipping fat jar?
Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 04/01/2007, at 5:21 AM, Andrus Adamchik wrote:
> That's true. I am trying to find an equally usable solution. So far
> I can think of a "lib/third-party" folder that I mentioned (and put
> into the new assembly descriptor).
How about a very low tech approach. Create a file as part of the
deployment (or a web page for that matter), which lists every
dependency, the appropriate version (or range of versions), and the
URL of the place to get the jar. We do that in our own project so
that we can easily track what we are using and where we got it from.
When Cayenne moved to skinny jars the way I figured out what
dependencies it needed was to keep running it, reading the exception
and then installing that jar. I guessed that the most recent version
of everything was the best thing to use, and they worked fine, but it
would be nice to know exactly what versions of dependencies Cayenne
is being tested with without reading the maven xml files.
Ari Maniatis
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Shipping fat jar?
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Jan 3, 2007, at 8:04 PM, Kevin Menard wrote:
> I always liked having a fat JAR just because I didn't have to guess
> what
> Cayenne's dependencies were.
That's true. I am trying to find an equally usable solution. So far I
can think of a "lib/third-party" folder that I mentioned (and put
into the new assembly descriptor). All its contents can be copied to
WEB-INF/lib, and this also gives a chance to resolve version
conflicts with other frameworks that share the same dependencies with
Cayenne.
> Having said that, I won't cry over spilt milk if it's gone.
> Especially
> since I've migrated to maven and have a whole new lot of things to cry
> about :-(
Tell me about it. Every time I forget how bad Maven is, something new
comes up in Cayenne that I spend a week fixing. I guess third party
integration is the *only* reason for us to continue using Maven.
Since the rest of the world decided to play this game, we are stuck
in it too :-/
Andrus
RE: Shipping fat jar?
Posted by Kevin Menard <km...@servprise.com>.
I always liked having a fat JAR just because I didn't have to guess what
Cayenne's dependencies were. Even if I can dump everything into
WEB-INF, it's nice to know to whom each dependency belongs.
Having said that, I won't cry over spilt milk if it's gone. Especially
since I've migrated to maven and have a whole new lot of things to cry
about :-(
--
Kevin
> -----Original Message-----
> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> Sent: Tuesday, January 02, 2007 10:52 AM
> To: cayenne-dev@incubator.apache.org
> Subject: Shipping fat jar?
>
> I am considering whether we should stop shipping the "fat"
> cayenne.jar in 3.0 (would've been called
> cayenne-server-deps.jar according to the new naming
> convention). The original motivation for it goes back to the
> days when full CLASSPATH had to be specified when running
> "javac" and "java" from command line. So it saved quite a bit
> of typing. With Ant, Eclipse and war format this seems obsolete.
> Instead I thought we might include a minimal set of runtime
> dependencies in the "lib/third-party" folder.
>
> Anybody thinks it is a bad idea to get rid of the fat jar?
>
> Andrus
>