[m2] fileset

[Ashley Williams <ag...@mac.com>]

I have my source code on a single tree but wish to build two  
artifacts out of it with two different poms. Is there some concept  
such as a file set so that each project will only see the relevant  
files for compiling and jaring etc?

Thanks
- AW

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: [m2] maven, how to work on large projects

[dan tran <da...@gmail.com>]

On 9/1/05, Ashley Williams <ag...@mac.com> wrote: 
> 
> Definitely exposing my newbie status with Maven!
> 
> However I worked on a HUGE project with Ant and we did exactly that,
> ie had one source tree for all work. The way we stopped any
> particular class from one package using one from an "illegal" package
> was using various Ant masks, so that if for example you checked in
> class com.acme.model.MyModel.java that had an import to
> com.acme.ui.MyUI.java, it literally wouldn't compile as the Ant
> script would let your particular code see that package and cruise
> control would report an error.

 If you are able to move the package to its own source tree under 
a maven project , there is no need to set up any mask right?
Second, the developer only needs to download the minimal source to work with
rather then the whole source tree.
 
> In other words we solved dependency issues using java package based
> rules, enforcing them with ant scripts. Believe me compared to many
> projects I've been on it was a godsend seeing all the code in one
> directory. We even used clearcase config specs so that we could see
> just the code we were interested in so that our machines wouldn't
> fall over with the strain.
> 
> With regards to eclipse read the following url http://mindprod.com/
> jgloss/eclipse.html. For those that can't be bothered it explains how
> Eclipse is essentially a structured database which shouldn't surprise
> anybody who has previously used VisualAge when it wasn't ... well,
> dead. In fact with VisualAge we never ever used to export the source
> code to the filing system, we would just generate the customer
> release jars direct onto CD ready for customer updates every couple
> of months.

  
Cheers
> - AW
> 
> On 1 Sep 2005, at 22:57, dan tran wrote:
> 
> > On 9/1/05, Ashley Williams <ag...@mac.com> wrote:
> >
> >>
> >> Thanks, that should get me going for now, at least for the compile
> >> lifecycle (still need to think about recources etc). I'm actually
> >> trying to figure out a much broader way of working, i.e. imagine
> >> starting a project with a dozen developers all working on many source
> >> files. Am I mistaken in thinking that Maven tries to get you to
> >> define multiple source trees, one for each artifact?? If so then that
> >> seems counter intuitive to me: surely there should be just the one
> >> source tree with many maven projects applying their own masks.
> >>
> >
> > The filters are there to help out with the transition from legacy
> > build
> > system
> > to Maven. Occational we may want to do some filtering even within a
> > maven
> > project.
> > Once source tree for many maven projects sound dangerous,
> > basically you
> > have the potential of
> > a maven project depends on every other projects indirectly via the
> > central
> > source.
> >
> > To see where I'm coming from imagine a database of source code rather
> >
> >> than a file system, so that the only structure you have is on package
> >> names in that database and not some added notion of there being
> >> entirely separate areas both beginning with "com.". I understand that
> >> Eclipse uses some sort of source code database and would love to know
> >> Maven is bending in that direction also.
> >>
> >> Also maybe it's already in the works, but I think there should be a
> >> practical document on how to set up a large project using Maven as
> >> I'm sure that would speed up its adoption.
> >>
> >
> > I doubt eclipse is doing that.
> >
> > Just a few thoughts anyway.
> >
> >>
> >> - AW
> >>
> >> On 1 Sep 2005, at 22:06, dan tran wrote:
> >>
> >>
> >>> btw, this feature is not in alpha 3 thou, but the latest trunk
> >>> -D
> >>>
> >>> On 9/1/05, dan tran <da...@gmail.com> wrote:
> >>>
> >>>
> >>>>
> >>>> in Maven 1, you use sourceModifications
> >>>> in Maven 2, you use compiler plugin filter set
> >>>> -D
> >>>>
> >>>> On 9/1/05, Ashley Williams <ag...@mac.com> wrote:
> >>>>
> >>>>
> >>>>>
> >>>>> I have my source code on a single tree but wish to build two
> >>>>> artifacts out of it with two different poms. Is there some concept
> >>>>> such as a file set so that each project will only see the relevant
> >>>>> files for compiling and jaring etc?
> >>>>>
> >>>>> Thanks
> >>>>> - AW
> >>>>>
> >>>>> ------------------------------------------------------------------
> >>>>> --
> >>>>> -
> >>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
>

Re: [m2] maven, how to work on large projects

[Ashley Williams <ag...@mac.com>]

Definitely exposing my newbie status with Maven!

However I worked on a HUGE project with Ant and we did exactly that,  
ie had one source tree for all work. The way we stopped any  
particular class from one package using one from an "illegal" package  
was using various Ant masks, so that if for example you checked in  
class com.acme.model.MyModel.java that had an import to  
com.acme.ui.MyUI.java, it literally wouldn't compile as the Ant  
script would let your particular code see that package and cruise  
control would report an error.

In other words we solved dependency issues using java package based  
rules, enforcing them with ant scripts. Believe me compared to many  
projects I've been on it was a godsend seeing all the code in one  
directory. We even used clearcase config specs so that we could see  
just the code we were interested in so that our machines wouldn't  
fall over with the strain.

With regards to eclipse read the following url http://mindprod.com/ 
jgloss/eclipse.html. For those that can't be bothered it explains how  
Eclipse is essentially a structured database which shouldn't surprise  
anybody who has previously used VisualAge when it wasn't ... well,  
dead. In fact with VisualAge we never ever used to export the source  
code to the filing system, we would just generate the customer  
release jars direct onto CD ready for customer updates every couple  
of months.

Cheers
- AW

On 1 Sep 2005, at 22:57, dan tran wrote:

> On 9/1/05, Ashley Williams <ag...@mac.com> wrote:
>
>>
>> Thanks, that should get me going for now, at least for the compile
>> lifecycle (still need to think about recources etc). I'm actually
>> trying to figure out a much broader way of working, i.e. imagine
>> starting a project with a dozen developers all working on many source
>> files. Am I mistaken in thinking that Maven tries to get you to
>> define multiple source trees, one for each artifact?? If so then that
>> seems counter intuitive to me: surely there should be just the one
>> source tree with many maven projects applying their own masks.
>>
>
>  The filters are there to help out with the transition from legacy  
> build
> system
> to Maven. Occational we may want to do some filtering even within a  
> maven
> project.
>  Once source tree for many maven projects sound dangerous,  
> basically you
> have the potential of
> a maven project depends on every other projects indirectly via the  
> central
> source.
>
> To see where I'm coming from imagine a database of source code rather
>
>> than a file system, so that the only structure you have is on package
>> names in that database and not some added notion of there being
>> entirely separate areas both beginning with "com.". I understand that
>> Eclipse uses some sort of source code database and would love to know
>> Maven is bending in that direction also.
>>
>> Also maybe it's already in the works, but I think there should be a
>> practical document on how to set up a large project using Maven as
>> I'm sure that would speed up its adoption.
>>
>
>  I doubt eclipse is doing that.
>
> Just a few thoughts anyway.
>
>>
>> - AW
>>
>> On 1 Sep 2005, at 22:06, dan tran wrote:
>>
>>
>>> btw, this feature is not in alpha 3 thou, but the latest trunk
>>> -D
>>>
>>> On 9/1/05, dan tran <da...@gmail.com> wrote:
>>>
>>>
>>>>
>>>> in Maven 1, you use sourceModifications
>>>> in Maven 2, you use compiler plugin filter set
>>>> -D
>>>>
>>>> On 9/1/05, Ashley Williams <ag...@mac.com> wrote:
>>>>
>>>>
>>>>>
>>>>> I have my source code on a single tree but wish to build two
>>>>> artifacts out of it with two different poms. Is there some concept
>>>>> such as a file set so that each project will only see the relevant
>>>>> files for compiling and jaring etc?
>>>>>
>>>>> Thanks
>>>>> - AW
>>>>>
>>>>> ------------------------------------------------------------------ 
>>>>> --
>>>>> -
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: [m2] fileset, how to work on large projects

[dan tran <da...@gmail.com>]

On 9/1/05, Ashley Williams <ag...@mac.com> wrote: 
> 
> Thanks, that should get me going for now, at least for the compile
> lifecycle (still need to think about recources etc). I'm actually
> trying to figure out a much broader way of working, i.e. imagine
> starting a project with a dozen developers all working on many source
> files. Am I mistaken in thinking that Maven tries to get you to
> define multiple source trees, one for each artifact?? If so then that
> seems counter intuitive to me: surely there should be just the one
> source tree with many maven projects applying their own masks.

 The filters are there to help out with the transition from legacy build 
system
to Maven. Occational we may want to do some filtering even within a maven 
project.
 Once source tree for many maven projects sound dangerous, basically you 
have the potential of
a maven project depends on every other projects indirectly via the central 
source.
  
To see where I'm coming from imagine a database of source code rather
> than a file system, so that the only structure you have is on package
> names in that database and not some added notion of there being
> entirely separate areas both beginning with "com.". I understand that
> Eclipse uses some sort of source code database and would love to know
> Maven is bending in that direction also.
> 
> Also maybe it's already in the works, but I think there should be a
> practical document on how to set up a large project using Maven as
> I'm sure that would speed up its adoption.

 I doubt eclipse is doing that. 

Just a few thoughts anyway.
> 
> - AW
> 
> On 1 Sep 2005, at 22:06, dan tran wrote:
> 
> > btw, this feature is not in alpha 3 thou, but the latest trunk
> > -D
> >
> > On 9/1/05, dan tran <da...@gmail.com> wrote:
> >
> >>
> >> in Maven 1, you use sourceModifications
> >> in Maven 2, you use compiler plugin filter set
> >> -D
> >>
> >> On 9/1/05, Ashley Williams <ag...@mac.com> wrote:
> >>
> >>>
> >>> I have my source code on a single tree but wish to build two
> >>> artifacts out of it with two different poms. Is there some concept
> >>> such as a file set so that each project will only see the relevant
> >>> files for compiling and jaring etc?
> >>>
> >>> Thanks
> >>> - AW
> >>>
> >>> --------------------------------------------------------------------
> >>> -
> >>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: users-help@maven.apache.org
> >>>
> >>>
> >>>
> >>
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
>

Re: [m2] fileset, how to work on large projects

[Ashley Williams <ag...@mac.com>]

Thanks, that should get me going for now, at least for the compile  
lifecycle (still need to think about recources etc). I'm actually  
trying to figure out a much broader way of working, i.e. imagine  
starting a project with a dozen developers all working on many source  
files. Am I mistaken in thinking that Maven tries to get you to  
define multiple source trees, one for each artifact?? If so then that  
seems counter intuitive to me: surely there should be just the one  
source tree with many maven projects applying their own masks.

To see where I'm coming from imagine a database of source code rather  
than a file system, so that the only structure you have is on package  
names in that database and not some added notion of there being  
entirely separate areas both beginning with "com.". I understand that  
Eclipse uses some sort of source code database and would love to know  
Maven is bending in that direction also.

Also maybe it's already in the works, but I think there should be a  
practical document on how to set up a large project using Maven as  
I'm sure that would speed up its adoption.

Just a few thoughts anyway.

- AW

On 1 Sep 2005, at 22:06, dan tran wrote:

> btw, this feature is not in alpha 3 thou, but the latest trunk
>  -D
>
>  On 9/1/05, dan tran <da...@gmail.com> wrote:
>
>>
>> in Maven 1, you use sourceModifications
>>  in Maven 2, you use compiler plugin filter set
>>  -D
>>
>>  On 9/1/05, Ashley Williams <ag...@mac.com> wrote:
>>
>>>
>>> I have my source code on a single tree but wish to build two
>>> artifacts out of it with two different poms. Is there some concept
>>> such as a file set so that each project will only see the relevant
>>> files for compiling and jaring etc?
>>>
>>> Thanks
>>> - AW
>>>
>>> -------------------------------------------------------------------- 
>>> -
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: [m2] fileset

[dan tran <da...@gmail.com>]

btw, this feature is not in alpha 3 thou, but the latest trunk
 -D

 On 9/1/05, dan tran <da...@gmail.com> wrote: 
> 
> in Maven 1, you use sourceModifications
>  in Maven 2, you use compiler plugin filter set
>  -D
> 
>  On 9/1/05, Ashley Williams <ag...@mac.com> wrote: 
> > 
> > I have my source code on a single tree but wish to build two
> > artifacts out of it with two different poms. Is there some concept 
> > such as a file set so that each project will only see the relevant
> > files for compiling and jaring etc?
> > 
> > Thanks
> > - AW
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> > 
> > 
>

Re: [m2] fileset

[dan tran <da...@gmail.com>]

in Maven 1, you use sourceModifications
 in Maven 2, you use compiler plugin filter set
 -D

 On 9/1/05, Ashley Williams <ag...@mac.com> wrote: 
> 
> I have my source code on a single tree but wish to build two
> artifacts out of it with two different poms. Is there some concept
> such as a file set so that each project will only see the relevant
> files for compiling and jaring etc?
> 
> Thanks
> - AW
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
>