Re: subproject JARs WAS: Multiple War Files (Architecture Question)

[Brett Porter <bp...@f2network.com.au>]

> Most definitely.
> 
> I will expand the section about the reactor in the user guide. But
> essentially a WAR file should contain a webview for a model. For me I
> typically build the model as a separate project and build the webview as
> another project. If you are providing a different view for the same
> model I think that definitely warrants a different build.
> 
> More to come in the user guide.
> 

Hi,

On this line, the WAR needs a dependency on the common JAR file(s). 
However, this means that you have to jar:install the common library, 
right? This is currently how we do this, and it is causing some issues 
in a multi-user environment.

Is there a way to have the WAR (and other projects for that matter), 
reference other reactor built JAR files without installing them into the 
repository? Will it also work if the WAR is built individually (out of 
the reactor), and locate the last built JAR from ../common-lib/target?

Cheers,
Brett

Re: subproject JARs WAS: Multiple War Files (Architecture Question)

[Brett Porter <bp...@f2network.com.au>]

> I fail to see this. People have repositories to do builds. If they're 
> doing builds with or without maven, they're copying around libraries. If 
> you have space to build your war file you must have space for usually 
> several copies of the libs involved.

Admittedly I'm still on beta-7 for the moment, and it downloads larger 
amounts.
Still the majority of these jars are exactly the same and it seems like 
overkill to make everyone keep a separate repo just so that one project 
they are playing with doesn't interfere with the others.

I'm not talking about working on shared components - I'm referring to 
"subprojects", for example the model code that goes inside a webapp.

> Helping with reducing the development costs of working with versioned 
> artifacts is what maven's all about. If you want an unstructured build 
> process, a tool thats all about structured builds isn't going to fit 
> your process very well. 
I'd hardly say its an unstructured build process. I appreciate all the 
structure its added, but I don't think that every checkout should 
require editing project xml to set pom.currentVersion to 
"bporter-dev-HEAD" or "bporter-dev-SOME_BRANCH". This is really the only 
solution I see to not only avoiding sharing a repository, but sharing a 
repository per project. Essentially what needs to happen in this case is 
that project.properties defines the local repo to be target/repo, and 
then reactor driven ones under it must do the same, using ../target/repo 
and so on.

> Seriously, fighting against the 'best practices' 
> that maven tries to enforce will more that likely mean that using it 
> will /cost you more/ than whatever you're doing right now. Maybe maven 
> isn't for you at this time?

I think you misinterpreted what I was trying to say (or more likely I 
did a poor job of saying it). And I've realised since that even if we 
versioned each release, it still doesn't solve the problem unless you 
put a developer & branch name on the version (or use developer/branch 
specific repositories).

I'm more than happy to figure use whatever disk space and get it if 
necessary, but to me, setting a repository into every CVS checkout 
doesn't sound like the right solution. I don't see why, in a reactor 
based build, the reactor can't use the built artifacts without having to 
install them.

Cheers,
Brett

Re: subproject JARs WAS: Multiple War Files (Architecture Question)

[Brian Ewins <Br...@btinternet.com>]

Brett Porter wrote:
> Hi Colin,
> 
> I've considered this as an option, and the only limitation I see is the 
> large amount of disk space (about 50mb per user for the repository). 
> Unfortunately, an extra 300mb on some of our machines won't fit very 
> easily, as small as that seems.
I fail to see this. People have repositories to do builds. If they're 
doing builds with or without maven, they're copying around libraries. If 
you have space to build your war file you must have space for usually 
several copies of the libs involved.

Buy some more disk space. Currently 50Mb of disk space costs less than a 
dollar [1][2]. How much of your company's time have you spent worrying 
about saving 50Mb?

[1] http://www.jcmit.com/diskprice.htm
[2] 20 GB for $68 - and its not on special offer, ie 17 cents for 50 Mb.
<http://www.dirtcheapdrives.com/Itemdesc.asp?CartId={B6E70A59-BED5-4C04-B36C-53959EF991D8}&ic=ST320014A>

> I'll still consider it as a solution though.
> 
> Maybe I'm trying to bandaid a problem in doing this, but another reason 
> is that we don't tend to version the subprojects, any more than we 
> version the WAR files. A date or cvs tag is sufficient. On occasion we 
> develop on two cvs branches at the same time, and wouldn't want to have 
> the artifcats overwriting each other in the repository.
> Obviously strictly versioning and "releasing" the artifacts individually 
> would solve the problem, but I have to consider that sometimes its 
> easier to work around it and let the other developers do what they want 
> to do than it is to convince them of and enforce best practices :) Plus 
> that probably introduces a little overhead into our project development 
> lifecycle that isn't strictly necessary.

Helping with reducing the development costs of working with versioned 
artifacts is what maven's all about. If you want an unstructured build 
process, a tool thats all about structured builds isn't going to fit 
your process very well. Seriously, fighting against the 'best practices' 
that maven tries to enforce will more that likely mean that using it 
will /cost you more/ than whatever you're doing right now. Maybe maven 
isn't for you at this time?

As other folk have pointed out, keeping things in snapshot versions will 
help mitigate this, but your builds will end up unrepeatable. Right now 
I'd guess that the only way you can repeat builds is to check out all 
the code from all your projects from a given date.

- Baz

Re: subproject JARs WAS: Multiple War Files (Architecture Question)

[Colin Sampaleanu <co...@exis.com>]

Actually working on two branches of a set of projects are a time is one 
of the main reasons why we do override the local repository per 'group 
of projects', since otherwise the per machine local repository would 
have been fine (we only have one user per machine). Each branch ends up 
pointing to a different local repository, since it is just a relative 
directory a level or two up, off $basedir.

As for versioning subprojects, while a developer is doing builds for 
himself, we normally work with a snapshot or dev version (e.g. 1.1dev) 
which all the projects would be set to. It works pretty well, except 
when you get to qa or production builds, when it's more work than id 
like to change the versions, but I haven't tried Jason's changes yet 
(used for b8) to change the version in the project POM automatically.


Brett Porter wrote:

> Hi Colin,
>
> I've considered this as an option, and the only limitation I see is 
> the large amount of disk space (about 50mb per user for the 
> repository). Unfortunately, an extra 300mb on some of our machines 
> won't fit very easily, as small as that seems.
>
> I'll still consider it as a solution though.
>
> Maybe I'm trying to bandaid a problem in doing this, but another 
> reason is that we don't tend to version the subprojects, any more than 
> we version the WAR files. A date or cvs tag is sufficient. On occasion 
> we develop on two cvs branches at the same time, and wouldn't want to 
> have the artifcats overwriting each other in the repository.
> Obviously strictly versioning and "releasing" the artifacts 
> individually would solve the problem, but I have to consider that 
> sometimes its easier to work around it and let the other developers do 
> what they want to do than it is to convince them of and enforce best 
> practices :) Plus that probably introduces a little overhead into our 
> project development lifecycle that isn't strictly necessary.
>
> Any thoughts?
>
> Cheers,
> Brett
>
> Colin Sampaleanu wrote:
>
>> Brett Porter wrote:
>>
>> This is only an issue if the local repository (where jar:install or 
>> war:install install to) is actually shared between multiple users 
>> (either on the same machine or on multiple machines).
>>
>> One solution is to use a per user local repository (we actually go 
>> farther use a per 'group of projects' local repository), and use the 
>> idea of multiple remote repositories to exchange artifacts between 
>> users. That does mean you will have to do a deploy operation to the 
>> 'local remote repo' of those artifacts you need to share between users.
>>
>> Colin
>

Re: subproject JARs WAS: Multiple War Files (Architecture Question)

[Brett Porter <bp...@f2network.com.au>]

Hi Colin,

I've considered this as an option, and the only limitation I see is the 
large amount of disk space (about 50mb per user for the repository). 
Unfortunately, an extra 300mb on some of our machines won't fit very 
easily, as small as that seems.

I'll still consider it as a solution though.

Maybe I'm trying to bandaid a problem in doing this, but another reason 
is that we don't tend to version the subprojects, any more than we 
version the WAR files. A date or cvs tag is sufficient. On occasion we 
develop on two cvs branches at the same time, and wouldn't want to have 
the artifcats overwriting each other in the repository.
Obviously strictly versioning and "releasing" the artifacts individually 
would solve the problem, but I have to consider that sometimes its 
easier to work around it and let the other developers do what they want 
to do than it is to convince them of and enforce best practices :) Plus 
that probably introduces a little overhead into our project development 
lifecycle that isn't strictly necessary.

Any thoughts?

Cheers,
Brett

Colin Sampaleanu wrote:
> Brett Porter wrote:
> 
> This is only an issue if the local repository (where jar:install or 
> war:install install to) is actually shared between multiple users 
> (either on the same machine or on multiple machines).
> 
> One solution is to use a per user local repository (we actually go 
> farther use a per 'group of projects' local repository), and use the 
> idea of multiple remote repositories to exchange artifacts between 
> users. That does mean you will have to do a deploy operation to the 
> 'local remote repo' of those artifacts you need to share between users.
> 
> Colin
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-maven-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-maven-user-help@jakarta.apache.org

Re: subproject JARs WAS: Multiple War Files (Architecture Question)

[Colin Sampaleanu <co...@exis.com>]

Brett Porter wrote:

>> Most definitely.
>>
>> I will expand the section about the reactor in the user guide. But
>> essentially a WAR file should contain a webview for a model. For me I
>> typically build the model as a separate project and build the webview as
>> another project. If you are providing a different view for the same
>> model I think that definitely warrants a different build.
>>
>> More to come in the user guide.
>>
>
> Hi,
>
> On this line, the WAR needs a dependency on the common JAR file(s). 
> However, this means that you have to jar:install the common library, 
> right? This is currently how we do this, and it is causing some issues 
> in a multi-user environment.
>
> Is there a way to have the WAR (and other projects for that matter), 
> reference other reactor built JAR files without installing them into 
> the repository? Will it also work if the WAR is built individually 
> (out of the reactor), and locate the last built JAR from 
> ../common-lib/target?

This is only an issue if the local repository (where jar:install or 
war:install install to) is actually shared between multiple users 
(either on the same machine or on multiple machines).

One solution is to use a per user local repository (we actually go 
farther use a per 'group of projects' local repository), and use the 
idea of multiple remote repositories to exchange artifacts between 
users. That does mean you will have to do a deploy operation to the 
'local remote repo' of those artifacts you need to share between users.

Colin