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
