Re: Maven: Aggregation and unpublished modules

[Christian Grobmeier <gr...@gmail.com>]

Today I read a suggestion from Mark Struberg on the Commons Dev list
about a pretty cool maven plugin.
It might help on the sleeping discussion of reorganizing the mvn structure.

http://maven.apache.org/plugins/maven-shade-plugin/

"This plugin provides the capability to package the artifact in an
uber-jar, including its dependencies and to shade - i.e. rename - the
packages of some of the dependencies."

With this package, Cayenne might provide cayenne-server/client jars
for the "normal users" without touching the mvn layout which is
expected by a developer.

I have not used it before, but would like throw that into the
discussion. What do you think of it?

Cheers
Christian

On Mon, Apr 18, 2011 at 11:32 AM, Andrus Adamchik
<an...@objectstyle.org> wrote:
> The original idea of having "private" (aka "unpublished") modules that are aggregated into bigger public modules was about consistent picture that we wanted to present to the end users.
>
> I always imagined ideal Cayenne as a self-contained drag-and-drop lib that does not require special installation, and ideally has no third-party dependencies. It originated from the earlier days of manual CLASSPATH, but some of this has merit these days as well. Third-party dependencies have version conflicts with same dependencies coming from other libs, so we worked on reducing the number of them (in 3.1 it is just c-collections which should go too, c-logging and velocity.).
>
> Now a single Cayenne jar does not have direct technical benefits. In a way it is a "feel good" thing these days. However let's look at the factors that led us to creating it:
>
> 1. Cross JDK builds. We don't have it in this iteration, but we used to have it before and may have it in the future. A single jar would provide features of the newer Java under newer JRE, and seamlessly degrade under older JRE (e.g. that's how we implemented annotations support).
>
> 2. cayenne-client.jar optimized for size. We never had a clean separation between cayenne-common, cayenne-server and cayenne-client. So cayenne-client was a stripped-down version of cayenne-server without the DB connection layer. This is another kludge from the Ant days. And another dimension in addition to JDK.
>
> So say we refactor everything, merge cayenne-di with parts of cayenne-server into a new cayenne-common, remove all the kludges and start supporting Java 9 extensions. The runtime modules will be these:
>
> * cayenne-common.jar (say we merge di in here)
> * cayenne-common-java9.jar
> * cayenne-server.jar
> * cayenne-server-java9.jar
> * cayenne-client.jar
> * cayenne-client-java9.jar
>
> plus some build or other extensions:
>
> * cayenne-project.jar
> * cayenne-tools.jar
> * cayenne-lifecycle.jar
>
> So should we aggregate them for downloadable distro, but not Maven? Should we give up on aggregation completely and use other means to reduce confusion?
>
> (Also notice that I am not touching the Modeler in this discussion as the Modeler distro is opaque and we can reorganize it internally as much as we'd like. I am only concerned about the runtime libraries and somewhat about the build tools).
>
> Andrus
>
>
>



-- 
http://www.grobmeier.de

Re: Maven: Aggregation and unpublished modules

[Christian Grobmeier <gr...@gmail.com>]

>
> I don't know that solves our problem from my initial understanding. Shade
> will rename the classes, where our main problem is our hierarchy of poms. We
> have an artificially flattened hierarchy to avoid end users seeing a regular
> maven pom tree.

With Shade Cayenne could have a regular maven pom tree in reality -
but for users who don't want that pom tree, Shade can create a huge
jar for them.

> I don't see how Shade will create anything but an enormous mess between svn
> source, jar output, javadocs and bug reports.

Actually having "unpublished modules" and "published" ones is not very
good also,  - imho. The current structure is very difficult to
understand. I know, you said only developers must care on it. But I
think otherwise, as this is open source. Every user is somehow a
potential developer too.

Cheers
Christian

Re: Maven: Aggregation and unpublished modules

[Aristedes Maniatis <ar...@maniatis.org>]

On Sat Jul 30 20:34:00 2011, Christian Grobmeier wrote:
> Today I read a suggestion from Mark Struberg on the Commons Dev list
> about a pretty cool maven plugin.
> It might help on the sleeping discussion of reorganizing the mvn structure.
> 
> http://maven.apache.org/plugins/maven-shade-plugin/
> 
> "This plugin provides the capability to package the artifact in an
> uber-jar, including its dependencies and to shade - i.e. rename - the
> packages of some of the dependencies."
> 
> With this package, Cayenne might provide cayenne-server/client jars
> for the "normal users" without touching the mvn layout which is
> expected by a developer.
> 
> I have not used it before, but would like throw that into the
> discussion. What do you think of it?
> 
> Cheers
> Christian
> 
> On Mon, Apr 18, 2011 at 11:32 AM, Andrus Adamchik
> <an...@objectstyle.org>  wrote:
>> The original idea of having "private" (aka "unpublished") modules that are aggregated into bigger public modules was about consistent picture that we wanted to present to the end users.
>>
>> I always imagined ideal Cayenne as a self-contained drag-and-drop lib that does not require special installation, and ideally has no third-party dependencies. It originated from the earlier days of manual CLASSPATH, but some of this has merit these days as well. Third-party dependencies have version conflicts with same dependencies coming from other libs, so we worked on reducing the number of them (in 3.1 it is just c-collections which should go too, c-logging and velocity.).
>>
>> Now a single Cayenne jar does not have direct technical benefits. In a way it is a "feel good" thing these days. However let's look at the factors that led us to creating it:
>>
>> 1. Cross JDK builds. We don't have it in this iteration, but we used to have it before and may have it in the future. A single jar would provide features of the newer Java under newer JRE, and seamlessly degrade under older JRE (e.g. that's how we implemented annotations support).
>>
>> 2. cayenne-client.jar optimized for size. We never had a clean separation between cayenne-common, cayenne-server and cayenne-client. So cayenne-client was a stripped-down version of cayenne-server without the DB connection layer. This is another kludge from the Ant days. And another dimension in addition to JDK.
>>
>> So say we refactor everything, merge cayenne-di with parts of cayenne-server into a new cayenne-common, remove all the kludges and start supporting Java 9 extensions. The runtime modules will be these:
>>
>> * cayenne-common.jar (say we merge di in here)
>> * cayenne-common-java9.jar
>> * cayenne-server.jar
>> * cayenne-server-java9.jar
>> * cayenne-client.jar
>> * cayenne-client-java9.jar
>>
>> plus some build or other extensions:
>>
>> * cayenne-project.jar
>> * cayenne-tools.jar
>> * cayenne-lifecycle.jar
>>
>> So should we aggregate them for downloadable distro, but not Maven? Should we give up on aggregation completely and use other means to reduce confusion?
>>
>> (Also notice that I am not touching the Modeler in this discussion as the Modeler distro is opaque and we can reorganize it internally as much as we'd like. I am only concerned about the runtime libraries and somewhat about the build tools).
>>
>> Andrus
>>
>>
>>

I don't know that solves our problem from my initial understanding. 
Shade will rename the classes, where our main problem is our hierarchy 
of poms. We have an artificially flattened hierarchy to avoid end users 
seeing a regular maven pom tree.

I don't see how Shade will create anything but an enormous mess between 
svn source, jar output, javadocs and bug reports.

-- 
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A