Maven: Problem in including/excluding some java packages in the src while creating a jar

[Jack Neilson]

Hi All,


I have a requirement to build a maven project into different jars, There are
10 different java packages

in the src and I want about 4 different jars to be generated from a single
pom.xml. I am trying to create

different profile for each jar I want to create in the same pom.xml. I am
trying to use include/exclude tags to

the include/exclude package(pattern matching). Everytime I run the pom.xml
with a specific profile it is creating the

jar with all the packages in it. Please help.



 <plugin>

                <groupId>org.apache.maven.plugins</groupId>

                <artifactId>maven-resources-plugin</artifactId>

                <version>2.3</version>

        </plugin>

<plugin>

<artifactId>maven-compiler-plugin

</artifactId>

<version>2.0.2</version>

<configuration>

<argLine>-ea -Xmx1024m</argLine>

<fork>true</fork>

<source>1.5</source>

<target>1.5</target>

<excludes>

          <exclude>**/pojo/**</exclude>

          <exclude>**/util/**</exclude>

                      </excludes>



<includes>

<include>**/moto/**</include>

</includes>

</configuration>

</plugin>




Thanks in Advance!

[Anders Hammar]

Don't fight Maven! Create one project for each artifact you want, it's a
Maven Golden Rule.

/Anders

On Fri, Aug 20, 2010 at 07:38, Jack Neilson <[hidden email]> wrote:

> Hi All,
>
>
> I have a requirement to build a maven project into different jars, There
> are
> 10 different java packages
>
> in the src and I want about 4 different jars to be generated from a single
> pom.xml. I am trying to create
>
> different profile for each jar I want to create in the same pom.xml. I am
> trying to use include/exclude tags to
>
> the include/exclude package(pattern matching). Everytime I run the pom.xml
> with a specific profile it is creating the
>
> jar with all the packages in it. Please help.
>
>
>
>  <plugin>
>
>                <groupId>org.apache.maven.plugins</groupId>
>
>                <artifactId>maven-resources-plugin</artifactId>
>
>                <version>2.3</version>
>
>        </plugin>
>
> <plugin>
>
> <artifactId>maven-compiler-plugin
>
> </artifactId>
>
> <version>2.0.2</version>
>
> <configuration>
>
> <argLine>-ea -Xmx1024m</argLine>
>
> <fork>true</fork>
>
> <source>1.5</source>
>
> <target>1.5</target>
>
> <excludes>
>
>          <exclude>**/pojo/**</exclude>
>
>          <exclude>**/util/**</exclude>
>
>                      </excludes>
>
>
>
> <includes>
>
> <include>**/moto/**</include>
>
> </includes>
>
> </configuration>
>
> </plugin>
>
>
>
>
> Thanks in Advance!
>

[Eric Haszlakiewicz]

>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]] On
>Behalf Of Anders Hammar
>
>Don't fight Maven! Create one project for each artifact you want, it's
a
>Maven Golden Rule.
>
>/Anders

So what do you do when your jar files actually have some of the same
contents?  Are you going to make multiple copies of your source files?
One option I could think of is having multiple pom.xml's in a directory
(e.g. pom_1.xml, pom_2.xml, etc...) and running maven with each one, but
if the include/exclude stuff doesn't work, that won't help.

Even if trying to build 10 different jar files from one pom isn't
recommended, don't you think it would be a bit nicer of you to explain
why the include/exclude lines don't work, instead of just brushing it
away?

So, ignoring the fact that he's building different jar, and looking at
the snippet he provided:
Based on what the docs for the maven-compiler-plugin say, it looks to me
like that configuration should work, so either it's a bug in the plugin,
or there's some quirk about the configuration that is preventing it from
working.
Jack, I'd recommend putting together a minimal pom with a couple of
source files, and check whether the exclude/include stuff works for
that.  If it still doesn't, post the whole pom.xml file, and the exact
mvn command you use.

eric

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Anders Hammar]

You're bringing up a different question than he is. He said he was trying to
create more than one artifact from one project. I'm just trying to stop him
from going down THE COMPLETELY WRONG PATH.

What happens is that someone doesn't follow Maven conventions. Later on
he/she is going to run into issues and come back here and ask us to help
sort things out. I'm trying to prevent that. Don't fight Maven! Or you're on
your own...

You may think I'm harsh, but I'm actually helping him.

/Anders

PS. The pom_1.xml, pom_2.xml, etc thought is very bad. Everyone, please
ignore that suggestion!

On Fri, Aug 20, 2010 at 20:36, Haszlakiewicz, Eric
<[hidden email]>wrote:

> >-----Original Message-----
> >From: [hidden email] [mailto:[hidden email]] On
> >Behalf Of Anders Hammar
> >
> >Don't fight Maven! Create one project for each artifact you want, it's
> a
> >Maven Golden Rule.
> >
> >/Anders
>
> So what do you do when your jar files actually have some of the same
> contents?  Are you going to make multiple copies of your source files?
> One option I could think of is having multiple pom.xml's in a directory
> (e.g. pom_1.xml, pom_2.xml, etc...) and running maven with each one, but
> if the include/exclude stuff doesn't work, that won't help.
>
> Even if trying to build 10 different jar files from one pom isn't
> recommended, don't you think it would be a bit nicer of you to explain
> why the include/exclude lines don't work, instead of just brushing it
> away?
>
> So, ignoring the fact that he's building different jar, and looking at
> the snippet he provided:
> Based on what the docs for the maven-compiler-plugin say, it looks to me
> like that configuration should work, so either it's a bug in the plugin,
> or there's some quirk about the configuration that is preventing it from
> working.
> Jack, I'd recommend putting together a minimal pom with a couple of
> source files, and check whether the exclude/include stuff works for
> that.  If it still doesn't, post the whole pom.xml file, and the exact
> mvn command you use.
>
> eric
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

[Russ Tremain-2]

you can make new projects just for packaging.
make these project depend on your jars.
then use the dependency plugin to unpack and repack.

you might find some useful ideas here (drill down to child poms):

        http://fisheye5.cenqua.com/browse/open-esb/esb-packages


At 10:38 PM -0700 8/19/10, Jack Neilson wrote:

>Hi All,
>
>
>I have a requirement to build a maven project into different jars, There are
>10 different java packages
>
>in the src and I want about 4 different jars to be generated from a single
>pom.xml. I am trying to create
>
>different profile for each jar I want to create in the same pom.xml. I am
>trying to use include/exclude tags to
>
>the include/exclude package(pattern matching). Everytime I run the pom.xml
>with a specific profile it is creating the
>
>jar with all the packages in it. Please help.
>
>
>
> <plugin>
>
>                <groupId>org.apache.maven.plugins</groupId>
>
>                <artifactId>maven-resources-plugin</artifactId>
>
>                <version>2.3</version>
>
>        </plugin>
>
><plugin>
>
><artifactId>maven-compiler-plugin
>
></artifactId>
>
><version>2.0.2</version>
>
><configuration>
>
><argLine>-ea -Xmx1024m</argLine>
>
><fork>true</fork>
>
><source>1.5</source>
>
><target>1.5</target>
>
><excludes>
>
>          <exclude>**/pojo/**</exclude>
>
>          <exclude>**/util/**</exclude>
>
>                      </excludes>
>
>
>
><includes>
>
><include>**/moto/**</include>
>
></includes>
>
></configuration>
>
></plugin>
>
>
>
>
>Thanks in Advance!

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[frankge]

I see several other people are also doing projects that are similar to some of mine.
- They need to pull artifacts from the Maven repositories. They are referred to as 'dependencies, although, there is nothing in the project that is actually dependent on the those artifacts (for compile, test, execution, etc.).
- The files of the artifacts must actually be acquired, not just referenced. This means the use of one or more plugins bound to an arbitrary phase that occurs in the needed sequence.
- files need to be 'post-processed' in some way. Some files need to be removed, moved, signed, repackaged, etc.
- there is no source code to be compiled or tested.
- No Maven install or deploy is performed.
- The results of the project are transferred to some distribution or production location. We used to call this deploying or installing.

It occurs to me that perhaps, rather than trying to kludge these projects onto the 'default' lifecycle, we should define an alternate lifecycle that better fits this kind of project.

In general, I would characterize these projects as getting files from Maven and sending them somewhere else, rather than producing files to be put into Maven repositories. We need one lifecycle to put thing into Maven and another to get them out.

Would anyone like to help define and implement such a product?
What would we call the lifecycle? How does the 'export' lifecycle sound.
What phases would it need to have?
Would any default bindings be appropriate?
Would we use words other than package, install, deploy to avoid confusion with the default lifecycle phases?

[hidden email]
      Software Development Infrastructure Specialist
        Process, Configuration, Tools, Automation, Distribution, Development, Analysis, Design, Architecture
      Comcast CVS, Radnor, PA; [phone]      →

[dennisl]

On 2010-08-20 07:38, Jack Neilson wrote:

> Hi All,
>
>
> I have a requirement to build a maven project into different jars, There are
> 10 different java packages
>
> in the src and I want about 4 different jars to be generated from a single
> pom.xml. I am trying to create
>
> different profile for each jar I want to create in the same pom.xml. I am
> trying to use include/exclude tags to
>
> the include/exclude package(pattern matching). Everytime I run the pom.xml
> with a specific profile it is creating the
>
> jar with all the packages in it. Please help.

The version of maven-compiler-plugin you are using (2.0.2) is very old
(over 3.5 years old). I'd suggest you try the latest version 2.3.1.

If you really (REALLY) want to go against Maven best practices and
create 4 JARs from a single source tree, I would go about it another
way. Instead of including/excluding during compilation I would do it
during packaging, i.e. try to use includes/excludes for the JAR plugin.

>
>
>
>  <plugin>
>
>                 <groupId>org.apache.maven.plugins</groupId>
>
>                 <artifactId>maven-resources-plugin</artifactId>
>
>                 <version>2.3</version>
>
>         </plugin>
>
> <plugin>
>
> <artifactId>maven-compiler-plugin
>
> </artifactId>
>
> <version>2.0.2</version>
>
> <configuration>
>
> <argLine>-ea -Xmx1024m</argLine>
>
> <fork>true</fork>
>
> <source>1.5</source>
>
> <target>1.5</target>
>
> <excludes>
>
>           <exclude>**/pojo/**</exclude>
>
>           <exclude>**/util/**</exclude>
>
>                       </excludes>
>
>
>
> <includes>
>
> <include>**/moto/**</include>
>
> </includes>
>
> </configuration>
>
> </plugin>
>
>
>
>
> Thanks in Advance!
>

--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[justinedelson]

Frank-
It sounds to me like you're describing a new packaging type, not
necessarily a new lifecycle. What do you see below that isn't mappable
to a phase in the default lifecycle.

Justin

On 8/20/10 4:17 PM, Gorham-Engard, Frank wrote:

> I see several other people are also doing projects that are similar to some of mine.
> - They need to pull artifacts from the Maven repositories. They are referred to as 'dependencies, although, there is nothing in the project that is actually dependent on the those artifacts (for compile, test, execution, etc.).
> - The files of the artifacts must actually be acquired, not just referenced. This means the use of one or more plugins bound to an arbitrary phase that occurs in the needed sequence.
> - files need to be 'post-processed' in some way. Some files need to be removed, moved, signed, repackaged, etc.
> - there is no source code to be compiled or tested.
> - No Maven install or deploy is performed.
> - The results of the project are transferred to some distribution or production location. We used to call this deploying or installing.
>
> It occurs to me that perhaps, rather than trying to kludge these projects onto the 'default' lifecycle, we should define an alternate lifecycle that better fits this kind of project.
>
> In general, I would characterize these projects as getting files from Maven and sending them somewhere else, rather than producing files to be put into Maven repositories. We need one lifecycle to put thing into Maven and another to get them out.
>
> Would anyone like to help define and implement such a product?
> What would we call the lifecycle? How does the 'export' lifecycle sound.
> What phases would it need to have?
> Would any default bindings be appropriate?
> Would we use words other than package, install, deploy to avoid confusion with the default lifecycle phases?
>
> [hidden email]
>       Software Development Infrastructure Specialist
>         Process, Configuration, Tools, Automation, Distribution, Development, Analysis, Design, Architecture
>       Comcast CVS, Radnor, PA; [phone]      →

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Russ Tremain-2]

anyone know of a web-service interface to any of the public maven
artifact lookup services?

tia,
-russ

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[mgainty]

what kinds of things would you look for in this webservice?
SOAP 1.0 or SOAP 1.1 or some other schema?

Martin Gainty
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
 
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.

> Date: Thu, 2 Dec 2010 13:43:45 -0800
> To: [hidden email]
> From: [hidden email]
> Subject: webservice for maven artifact search?
>
> anyone know of a web-service interface to any of the public maven
> artifact lookup services?
>
> tia,
> -russ
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

     

[Russ Tremain-2]

Well, if I were going to design something from scratch, I think a simple REST'ful api would suffice, perhaps similar to hudson:

        http://wiki.hudson-ci.org/display/HUDSON/Remote+access+API

(although don't need so many choices!)

So perhaps I should broaden my question - is there anything out there already, webservice or any other remote api?

[I'm doing another large maven conversion, and it would be helpful to be able to query/retrieve pomable dependency snippets into a text file.  The dependencies are currently encoded in 400+ ant files.]

:)

thx,
-russ

At 4:46 PM -0500 12/2/10, Martin Gainty wrote:

>what kinds of things would you look for in this webservice?
>SOAP 1.0 or SOAP 1.1 or some other schema?
>
>Martin Gainty
>
>> Date: Thu, 2 Dec 2010 13:43:45 -0800
>> To: [hidden email]
>> From: [hidden email]
>> Subject: webservice for maven artifact search?
>>
>> anyone know of a web-service interface to any of the public maven
>> artifact lookup services?
>>
>> tia,
>> -russ
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Jason van Zyl]

http://www.sonatype.com/people/2008/11/searching-with-the-sonatype-nexus-rest-api-groovy/

On Dec 2, 2010, at 6:57 PM, Russ Tremain wrote:

> Well, if I were going to design something from scratch, I think a simple REST'ful api would suffice, perhaps similar to hudson:
>
> http://wiki.hudson-ci.org/display/HUDSON/Remote+access+API
>
> (although don't need so many choices!)
>
> So perhaps I should broaden my question - is there anything out there already, webservice or any other remote api?
>
> [I'm doing another large maven conversion, and it would be helpful to be able to query/retrieve pomable dependency snippets into a text file.  The dependencies are currently encoded in 400+ ant files.]
>
> :)
>
> thx,
> -russ
>
> At 4:46 PM -0500 12/2/10, Martin Gainty wrote:
>> what kinds of things would you look for in this webservice?
>> SOAP 1.0 or SOAP 1.1 or some other schema?
>>
>> Martin Gainty
>>
>>> Date: Thu, 2 Dec 2010 13:43:45 -0800
>>> To: [hidden email]
>>> From: [hidden email]
>>> Subject: webservice for maven artifact search?
>>>
>>> anyone know of a web-service interface to any of the public maven
>>> artifact lookup services?
>>>
>>> tia,
>>> -russ
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>  
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.

 -- Buddha

[Brian Fox-2]

Repository.apache.org exposes nexus' rest interface

--mobile

On Dec 2, 2010, at 4:44 PM, Russ Tremain <[hidden email]> wrote:

> anyone know of a web-service interface to any of the public maven artifact lookup services?
>
> tia,
> -russ
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Anders Hammar]

As always, if you tell us what you're trying to do we could maybe offer
better solutions.
As an alternative, possibly you could use the index file that Maven central
and many other repos provide? Or does the business requirements demand that
web service is used?

/Anders

On Fri, Dec 3, 2010 at 04:03, Brian Fox <[hidden email]> wrote:

> Repository.apache.org exposes nexus' rest interface
>
> --mobile
>
> On Dec 2, 2010, at 4:44 PM, Russ Tremain <[hidden email]> wrote:
>
> > anyone know of a web-service interface to any of the public maven
> artifact lookup services?
> >
> > tia,
> > -russ
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>