Thanks for the report, Pierre-Arnaud. More inline

Pierre-Arnaud Marcelot wrote:
> Hi all,
>
> Here is a status on the last issues we have, and some proposals to 
> solve them.
>
> *• Studio Maven Repository*
> The Studio Maven Repository is currently located at 
> http://people.apache.org/~felixk/studio-eclipse-m2/ 
> <http://people.apache.org/%7Efelixk/studio-eclipse-m2/>.
> This is not really an ideal situation and we have to find it a better 
> solution.
> If all the Eclipse dependencies we need were on the standard Maven 
> repositories, Emmanuel and I think we could get rid of our project 
> specific repository by deploying our studio related jars 
> (studio-launcher, studio-dsml-parser, etc.) on those standard Maven 
> repositories. This way all our dependencies would be on Maven 
> repositories.
I'm the one who don't like Maven when Maven claim to be a Configuration  
Management System. Maven is a cool and good tool (with some itches, but 
every tool has some), but in no way having a common remote repo is a 
solution. People can still FU the existing files on the repo. Now, I 
don't think we can fix this pb here. We can't have a specific repo on 
people.a.o, we can't rely on the current maven repo because someone 
found smart to push a jar with the very same versions than the original 
files (just to add a useless maven related line in a Manifest, which 
obviously changed the signature of this jar, and directly created a 
problem for us), so we are stuck.
>
> As we can't do that at the moment, I propose we switch back to a local 
> maven repository located inside SVN.
Yes.
> This is exactly like we're doing with Ant/Ivy at the moment.
And it works.

I didn't knew maven allowed to do the very same thing (in fact, I tried, 
but didn't succeeded. I find it so stupid that we have to rely only on a 
HTTP repo...). If it's possible, I would say : just do it.
> It takes some extra time when doing a checkout, but it does not create 
> overload on the people.apache.org <http://people.apache.org> server 
> each time we build Studio.
I don't really care because the subversion server are pretty ok, and 
more than that, I don't think we have so many people who download the 
sources _and_ build the code.
>
> *• Parent Pom*
> We currently depend on the 9-SNAPSHOT version of the Directory project 
> pom.
> This situation forces us to checkout and build Apache DS first, before 
> building Apache Directory Studio.
> It takes a lot of time... :(
> I would suggest we use the 8 version of the Directory project pom, the 
> last published version available.
> WDYT ?*
> *
Take 8. We are depending on ADS 1.5.1, not 1.5.2.
> *
> • Apache DS and Shared dependencies*
> The last problem we face is our dependencies to jars of the Apache DS 
> project.
> The Shared dependencies are no longer a problem as we'll have a new 
> version released especially for Studio very soon (tomorrow maybe...).
> The Apache DS dependencies have been checked by Emmanuel and he told 
> me that we can use the 1.5.1 version (available on Maven repositories).
> So, there should be no more dependencies issues.
I tested the strudio with project 8 and ADS 1.5.1 jar and shared trunk. 
It works. We just have to release the shared-ldap jar, 0.9.8 version.
>
> With the 2 last problems resolved, we won't need anymore to checkout 
> and build Apache DS prior to building Apache Directory Studio and 
> we'll have, I think, a working and release ready Maven build.
> A build system which could be subject to a vote for switching to it...
Well, I don't really think it deserves a vote, as those who worked hard 
to make it work are the one who also work on Studio. I can't imagine 
that someone -1 this move after 2 months of hard work. But may be I'm 
wrong. Your call Pierre-Arnaud !

We are seing the light at the end of the tunnel, thanks to Felix and 
Pierre-Arnaud !!!


"The light you see at the end of the tunnel is generally the train which 
arrives"

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org