Re: Maven on a Terminal Server

2012-09-28 Thread Graham Leggett
On 28 Sep 2012, at 4:15 PM, Pascal Rapicault  wrote:

> I'm currently doing work for Ericsson where we have a similar setup (Terminal 
> Server on windows and AFS on *nix).
> The difficulty in this setup is not network access but limited user storage 
> so the goal is to try to share as much as possible among the users. This was 
> such a concern for Ericsson that they built extensions to Eclipse to make 
> sure that users would not have copies of the plugins they install in their 
> user folder but would run them from a shared location.

If you go down this road you have to be very careful - SNAPSHOTs are 
unsharable, because they are unrepeatable. I would be confused out of my mind 
if my perfectly working SNAPSHOT suddenly stopped working because it was 
silently replaced by someone else's SNAPSHOT.

As to released artefacts these could be shared, this would be relatively easy 
to script. Have a "master" repository, and every so often sweep the local 
user's repos for files that are common in name and content to the master repo, 
then hard link a replacement.

> Now to go back to Maven I can see how the desire to share artifacts applies 
> since I've had the same discussion last week :). Basically the local maven 
> repo is made of 3 things:
>   - released versions of non-corporate artifacts (e.g. content from 
> central, jboss, etc.)
>   - released versions of corporate artifacts
>   - snapshots versions of corporate artifacts
>   (yes there is snapshot of non corporate but I think they represent a 
> minority)
> 
> Using this as a starting point, I think it would be possible to address this 
> in a clean way the problem if we were to make the local maven repository a 
> bit smarter (i.e. code change :)) . For example I think a solution that could 
> work is to have a read only shared cache that only contains the released 
> artifacts and have that chained to the local maven repository. This way when 
> an artifact is looked up, it is first looked up in the local cache, then in 
> the shared cache, and if it is not availble, then it is downloaded and stored 
> into the local cache (note that  this solution of chained maven repo could 
> also be used to isolate snapshot from released artifacts)
> 
> Since the shared cache is read only, its population could be done by doing a 
> dump of the repo manager content into the shared folder at regular interval.

The trouble with this is that you still have to populate and maintain the 
shared cache on a regular basis, so you're doomed to some sort of scripting 
anyway. Keep all the magic in the script, and you don't have to touch maven at 
all. That means no special plugins, no maven behaviour unique to your 
environment, no documentation or training needed.

Regards,
Graham
--



smime.p7s
Description: S/MIME cryptographic signature


Re: Maven on a Terminal Server

2012-09-28 Thread Pascal Rapicault
I'm currently doing work for Ericsson where we have a similar setup (Terminal 
Server on windows and AFS on *nix).
The difficulty in this setup is not network access but limited user storage so 
the goal is to try to share as much as possible among the users. This was such 
a concern for Ericsson that they built extensions to Eclipse to make sure that 
users would not have copies of the plugins they install in their user folder 
but would run them from a shared location.

Now to go back to Maven I can see how the desire to share artifacts applies 
since I've had the same discussion last week :). Basically the local maven repo 
is made of 3 things:
- released versions of non-corporate artifacts (e.g. content from 
central, jboss, etc.)
- released versions of corporate artifacts
- snapshots versions of corporate artifacts
(yes there is snapshot of non corporate but I think they represent a 
minority)

Using this as a starting point, I think it would be possible to address this in 
a clean way the problem if we were to make the local maven repository a bit 
smarter (i.e. code change :)) . For example I think a solution that could work 
is to have a read only shared cache that only contains the released artifacts 
and have that chained to the local maven repository. This way when an artifact 
is looked up, it is first looked up in the local cache, then in the shared 
cache, and if it is not availble, then it is downloaded and stored into the 
local cache (note that  this solution of chained maven repo could also be used 
to isolate snapshot from released artifacts)

Since the shared cache is read only, its population could be done by doing a 
dump of the repo manager content into the shared folder at regular interval.

Pascal

On 2012-09-28, at 4:58 AM, Barrie Treloar wrote:

> On Fri, Sep 28, 2012 at 1:15 PM, Brett Porter  wrote:
>> Hi Terry,
>> 
>> On 28/09/2012, at 9:41 AM, "Sposato, Terry"  
>> wrote:
>> 
>>> Hi,
>>> 
>>> We currently use Nexus as our project’s local repository server which works 
>>> well.
>>> We also have a Terminal server which offshore developers access to do their 
>>> development/testing/building etc.
>>> I want to know if there is a way of having all these users access the same 
>>> .m2 local repository which maven3 is using in a safe way?
>>> I have currently set the path in settings.xml to use a local path, which at 
>>> a high level works, I am just not sure if this will cause issues moving 
>>> forward?
>>> 
>>> Please reply all as I am currently not subscribed to the list.
>> 
>> Sharing the local repository is not advised. There's no external locking on 
>> files written there.
>> 
>> Given you have a repository manager, as long as you have one geographically 
>> close to that terminal server (or on the machine), you typically give each 
>> user a local repository and are free to clean it out frequently if needed.
> 
> And for other non-Maven security reasons, you would want to have each
> person have a separate account on your terminal server anyway.
> 
> So shared accounts aren't advised are generally considered a "bad thing"(tm)
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


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



Re: Maven on a Terminal Server

2012-09-28 Thread Barrie Treloar
On Fri, Sep 28, 2012 at 1:15 PM, Brett Porter  wrote:
> Hi Terry,
>
> On 28/09/2012, at 9:41 AM, "Sposato, Terry"  
> wrote:
>
>> Hi,
>>
>> We currently use Nexus as our project’s local repository server which works 
>> well.
>> We also have a Terminal server which offshore developers access to do their 
>> development/testing/building etc.
>> I want to know if there is a way of having all these users access the same 
>> .m2 local repository which maven3 is using in a safe way?
>> I have currently set the path in settings.xml to use a local path, which at 
>> a high level works, I am just not sure if this will cause issues moving 
>> forward?
>>
>> Please reply all as I am currently not subscribed to the list.
>
> Sharing the local repository is not advised. There's no external locking on 
> files written there.
>
> Given you have a repository manager, as long as you have one geographically 
> close to that terminal server (or on the machine), you typically give each 
> user a local repository and are free to clean it out frequently if needed.

And for other non-Maven security reasons, you would want to have each
person have a separate account on your terminal server anyway.

So shared accounts aren't advised are generally considered a "bad thing"(tm)

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



Re: Maven on a Terminal Server

2012-09-27 Thread Brett Porter
Hi Terry,

On 28/09/2012, at 9:41 AM, "Sposato, Terry"  
wrote:

> Hi,
>  
> We currently use Nexus as our project’s local repository server which works 
> well.
> We also have a Terminal server which offshore developers access to do their 
> development/testing/building etc.
> I want to know if there is a way of having all these users access the same 
> .m2 local repository which maven3 is using in a safe way?
> I have currently set the path in settings.xml to use a local path, which at a 
> high level works, I am just not sure if this will cause issues moving forward?
>  
> Please reply all as I am currently not subscribed to the list.

Sharing the local repository is not advised. There's no external locking on 
files written there.

Given you have a repository manager, as long as you have one geographically 
close to that terminal server (or on the machine), you typically give each user 
a local repository and are free to clean it out frequently if needed.

Cheers,
Brett

--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter







Maven on a Terminal Server

2012-09-27 Thread Sposato, Terry
Hi,

We currently use Nexus as our project's local repository server which works 
well.
We also have a Terminal server which offshore developers access to do their 
development/testing/building etc.
I want to know if there is a way of having all these users access the same .m2 
local repository which maven3 is using in a safe way?
I have currently set the path in settings.xml to use a local path, which at a 
high level works, I am just not sure if this will cause issues moving forward?

Please reply all as I am currently not subscribed to the list.

Regards,

[cid:image001.jpg@01CD9D5D.20AA6650]

Terry Sposato
Deployment  |  Cloud Solutions  |  Telstra Operations
M  0413 922 189 |  E  
terry.spos...@team.telstra.com  |  W  
http://cloud.telstra.com

This communication may contain confidential or copyright information of Telstra 
Corporation Limited (ABN 33 051 775 556).
If you are not an intended recipient, you must not keep, forward, copy, use, 
save or rely on this communication, and any such
action is unauthorised and prohibited. If you have received this communication 
in error, please reply to this email to notify the
sender of its incorrect delivery, and then delete both it and your reply.