RE: Maven build and scripting was Re: [JBoss-dev] RE: Ongoing build changes: was RE: [JBoss-dev] OntheedgeoftheMavencliff
I read that thread and it looks like the idea is to refactor common into multiple top-level projects (option #2). If that's the case, you should be able to rely on the jar plugin as long as you are not trying to create JARs that contains classes from dependencies. --- Ruel Loehr <[EMAIL PROTECTED]> wrote: > In our current configuration, the jar plugin is not adequate. For a > given module, we need to build many artifacts (see the build forum post > here): > > http://www.jboss.com/index.html?module=bb&op=viewtopic&p=392#392 > > I spent some time looking at the assembly plugin as well, but did not > find it suitable for the following reasons. > > 1) It must be called manually. We don't want to have to call this for each > module. In Maven2, when you execute "mvn assembly:assembly" from a top-level project, it will run that goal on every subproject referenced. But, this assumes that you'd want to run assembly:assembly on every subproject. > 2) It lacks functionality for adding classes from dependencies into a > jar. E.g, I want to create a jar and add some classes from another > modules output. This is possible, but I'm not surprised that you didn't see how this is accomplished. The Assembly plugin is one of worst documented plugins of the bunch. You could create an assembly descriptor that would unpack a selected set of dependency jars. Although, I'd recommend against this. See the end of this message. > 3) It seemed to me overall that the assembly plugin was best used for > creating the final project structure, not for building the outputs of > each subproject. > I think that the most obvious use of the assembly plug-in is to use it to build final project distributions. A less obvious use would be to use it to create these JARs that contain mixtures of dependency jars. I'm just offering it as an example of something that could be done. I think the assembly plugin could probably do this, but it would be a stretch. I think this is a job for a custom plugin. Tim --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Maven build and scripting was Re: [JBoss-dev] RE: Ongoing build changes: was RE: [JBoss-dev] OntheedgeoftheMavencliff
We are mixing several issues here though. 1. Ruel's attempt to replicate the build using maven was a question as to whether maven could handle a screwed up build structure. 2. Since this is not ideal and maven has an even stricter notion of a source tree/per artificat, should the build be restructured to more closely mirror this notion to remove the hacks Ruel used. 3. There are additional changes being discussed with regard to breaking up existing cvs modules and artifacts (common -> jboss-common.jar) to separate out projects like jbossxb which should be evolvoing indepedently of the app server. 4. svn blah blah. The point I take from Adrian is that if we have to do something beyond what maven supports via an existing plugin, it needs to be encapsulated in a custom plugin. It cannot be ad hoc scripting in the build descriptors. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Ruel Loehr > Sent: Monday, February 13, 2006 8:44 AM > To: jboss-development@lists.sourceforge.net > Subject: RE: Maven build and scripting was Re: [JBoss-dev] > RE: Ongoing build changes: was RE: [JBoss-dev] > OntheedgeoftheMavencliff > > In our current configuration, the jar plugin is not adequate. > For a given module, we need to build many artifacts (see the > build forum post > here): > > http://www.jboss.com/index.html?module=bb&op=viewtopic&p=39233 > 33#392 > > I spent some time looking at the assembly plugin as well, but > did not find it suitable for the following reasons. > > 1) It must be called manually. We don't want to have to > call this for > each module. > 2) It lacks functionality for adding classes from > dependencies into a jar. E.g, I want to create a jar and add > some classes from another modules output. > 3) It seemed to me overall that the assembly plugin was best > used for creating the final project structure, not for > building the outputs of each subproject. > > If I am wrong, please correct me. > > Ruel Loehr > JBoss QA --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Maven build and scripting was Re: [JBoss-dev] RE: Ongoing build changes: was RE: [JBoss-dev] OntheedgeoftheMavencliff
In our current configuration, the jar plugin is not adequate. For a
given module, we need to build many artifacts (see the build forum post
here):
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=392#392
I spent some time looking at the assembly plugin as well, but did not
find it suitable for the following reasons.
1) It must be called manually. We don't want to have to call this for
each module.
2) It lacks functionality for adding classes from dependencies into a
jar. E.g, I want to create a jar and add some classes from another
modules output.
3) It seemed to me overall that the assembly plugin was best used for
creating the final project structure, not for building the outputs of
each subproject.
If I am wrong, please correct me.
Ruel Loehr
JBoss QA
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tim
OBrien
Sent: Sunday, February 12, 2006 12:36 PM
To: jboss-development@lists.sourceforge.net
Subject: Re: Maven build and scripting was Re: [JBoss-dev] RE: Ongoing
build changes: was RE: [JBoss-dev] OntheedgeoftheMavencliff
Seconding Adrian's suggestion below. Here's a pointer to Apache Axis2's
Subversion repository as
a cautionary example that is related to using Ant tags in Maven builds:
http://svn.apache.org/repos/asf/webservices/axis2/trunk/java/maven.xml
They moved to Maven 1, but they did so by just adapting existing Ant
build scripts into a
maven.xml file. Check out the trunk of Axis2; try to understand the
build system, and I think
you'll quickly come to the conclusion that Axis2 doesn't use Maven. It
uses Maven as a wrapper
around a core build that is still written in Ant. When a project moves
to Maven by wrapping
existing Ant build scripts, the end product is neither an Ant build nor
a Maven build, it is a
custom Frankenstein build that gains no benefit from Maven's life-cycle;
it doesn't benefit from
the reuse that are Maven plug-ins, and it takes just as much work to
manage as the original.
In the last two years most people have moved to Maven 1 from Ant, and I
don't think that the Maven
people did a good job of letting people know not to do this [make heavy
use of Ant tags]. People
tended to put customizations in maven.xml and then they had a bad
experience with Maven 1. (Then
they read the BileBlog, and now there is a siginificant portion of the
population that *hates*
Maven.)
Maven 2 was redesigned from the ground up to discourage build
customization via Ant tags. In
general, Maven 2 can handle almost anything you can throw at it, and,
when it can't, it is easy to
write a script in the form of a plugin (and if you really want to write
that plugin in Ant see:
http://maven.apache.org/guides/plugin/guide-ant-plugin-development.html)
What you are trying to do below is already handled by the jar plugin and
if that doesn't meet your
needs you can create an assembly descriptor. But, I wouldn't expect
people to just know that
because the docs are lacking.
I wouldn't recommend using the antrun plug-in even as a temporary
stop-gap. If you are going to
move to Maven 2, adopt it in full; otherwise, you'll end up in the same
situation as Axis2.
You'll have semi-adoption of Maven 2, but most of your build logic will
still be captured in Ant.
--- Adrian Brock <[EMAIL PROTECTED]> wrote:
> On the maven build in general, I don't like the kind of thing
> seen below. We might as well use ant than learn a new tool
> to do this???
>
> Good: Declarative information known to the build system
> Bad: Scripting or any other hack that breaks the information trail
>
> Is this just because our projects are hopelessly entangled?
>
>
>
> maven-antrun-plugin
> 1.0
>
>
>
>package
>
>
>
>
>
>
> jarfile="${basedir}/output/lib/jboss-common.jar"
>
> manifest="${basedir}/src/etc/default.mf">
> dir="${basedir}/output/classes">
>
>name="org/apache/xerces/**"/>
>
>
>
>
> jarfile="${basedir}/output/lib/jboss-common-client.jar"
>
> manifest="${basedir}/src/e
Re: Maven build and scripting was Re: [JBoss-dev] RE: Ongoing build changes: was RE: [JBoss-dev] OntheedgeoftheMavencliff
Seconding Adrian's suggestion below. Here's a pointer to Apache Axis2's
Subversion repository as
a cautionary example that is related to using Ant tags in Maven builds:
http://svn.apache.org/repos/asf/webservices/axis2/trunk/java/maven.xml
They moved to Maven 1, but they did so by just adapting existing Ant build
scripts into a
maven.xml file. Check out the trunk of Axis2; try to understand the build
system, and I think
you'll quickly come to the conclusion that Axis2 doesn't use Maven. It uses
Maven as a wrapper
around a core build that is still written in Ant. When a project moves to
Maven by wrapping
existing Ant build scripts, the end product is neither an Ant build nor a Maven
build, it is a
custom Frankenstein build that gains no benefit from Maven's life-cycle; it
doesn't benefit from
the reuse that are Maven plug-ins, and it takes just as much work to manage as
the original.
In the last two years most people have moved to Maven 1 from Ant, and I don't
think that the Maven
people did a good job of letting people know not to do this [make heavy use of
Ant tags]. People
tended to put customizations in maven.xml and then they had a bad experience
with Maven 1. (Then
they read the BileBlog, and now there is a siginificant portion of the
population that *hates*
Maven.)
Maven 2 was redesigned from the ground up to discourage build customization via
Ant tags. In
general, Maven 2 can handle almost anything you can throw at it, and, when it
can't, it is easy to
write a script in the form of a plugin (and if you really want to write that
plugin in Ant see:
http://maven.apache.org/guides/plugin/guide-ant-plugin-development.html)
What you are trying to do below is already handled by the jar plugin and if
that doesn't meet your
needs you can create an assembly descriptor. But, I wouldn't expect people to
just know that
because the docs are lacking.
I wouldn't recommend using the antrun plug-in even as a temporary stop-gap. If
you are going to
move to Maven 2, adopt it in full; otherwise, you'll end up in the same
situation as Axis2.
You'll have semi-adoption of Maven 2, but most of your build logic will still
be captured in Ant.
--- Adrian Brock <[EMAIL PROTECTED]> wrote:
> On the maven build in general, I don't like the kind of thing
> seen below. We might as well use ant than learn a new tool
> to do this???
>
> Good: Declarative information known to the build system
> Bad: Scripting or any other hack that breaks the information trail
>
> Is this just because our projects are hopelessly entangled?
>
>
>
> maven-antrun-plugin
> 1.0
>
>
>
>package
>
>
>
>
>
>
> jarfile="${basedir}/output/lib/jboss-common.jar"
>
> manifest="${basedir}/src/etc/default.mf">
> dir="${basedir}/output/classes">
>
>name="org/apache/xerces/**"/>
>
>
>
>
> jarfile="${basedir}/output/lib/jboss-common-client.jar"
>
> manifest="${basedir}/src/etc/default.mf">
> dir="${basedir}/output/classes">
>
>name="org/apache/xerces/**"/>
>name="org/jboss/deployment/**"/>
>
>
>
>
> jarfile="${basedir}/output/lib/namespace.jar"
>
> manifest="${basedir}/src/etc/default.mf">
> dir="${basedir}/output/classes">
>name="javax/xml/namespace/*"/>
>
>
>
>
> --
>
> Adrian Brock
> Chief Scientist
> JBoss Inc.
>
>
>
>
> ---
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> ___
> JBoss-Development mailing list
> JBoss-Development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jbo
