Hi Igor,
having thought about my problem for while I come to the conclusion that
I want to have the Maven group repository as the primary repository
where all Eclipse plugin artifacts have to go into. Any update sites or
P2 repositories I regard then as secondary representations which I want
to create / populate with Tycho by pulling the intended artifacts from
the primary repository.
I'm not sure whether the latter is already possible with Tycho.
What do you think about this approach?
Thanks!
-Max
On 2/19/2009 1:37 PM, Max Spring wrote:
On 2/19/2009 11:02 AM, Igor Fedorenko wrote:
Max,
If you do not mind, can you answer few questions to help me
understand your requirements better.
How do you want to use such update site? Install your
features/plugins into Eclipse? (you know you can build/deploy zipped
update site already, right?)
Some update sites will be advertised to other teams for consumption by
their own "private" means, i.e. Eclipse.
Some update sites will be consumed by our own build process to
populate (self-contained) Eclipse product images.
We then run automated system tests / GUI tests against that product
image (also using Tycho).
After these automated tests and manual testing succeeded, we put the
image under the control of Pulse for final deployment to the end-user.
Do you need old-style update site, p2 repository or both?
We have now transitioned into P2. I don't want to rule out that I
will get requests to also provide support for old-style update sites.
Although I have to say that I don't like it ;)
It's too clumsy: P2 Director is too slow.
I haven't figured out how to
- do bulk operations, e.g. installing multiple features from multiple
repositories with *one* P2 Director invocation,
- provision without running the target application (it always installs
in the running instance),
- sweep plugins by transitively following dependencies.
But probably I simply haven't spent sufficient time on these things,
or I'm spoiled by the ease of creating war files with Maven ;)
Do you want separate URL for each update site version or one URL for
all versions?
This is one of the crucial questions. I'm not sure what I actually want.
If I treated an update site as an artifact, I would get new update
sites with different URLs for each deployment, following the Maven
conventions.
On the other hand, an update site would be also capable of handling
multiple versions of its content.
Maybe I should distinguish exposed update sites from transient update
site?
In the latter case, do you want each new version to overwrite
previous site content or you want update site with all/some
historical versions?
I think I understand both options, but I'm not fully sure which one to
choose.
And, yes, we are adding support for hosted P2 repositories to Nexus ;-)
I'd be very eager to learn what P2 support within Nexus actually mean.
I read about this feature a couple of times, but never dove into details.
Regards,
-Max
--
Regards,
Igor
Max Spring wrote:
Hi Igor,
do you have suggestions for how to best handle the "management" of
update sites
in the context of Tycho, e.g. where to store them?
The infrastructure I'm building up is for separate teams who develop
Eclipse
plugins and want to publish them via update sites so that other
teams can
leverage them. To me an update site is basically just another form of
artifact
which I want to put somewhere and which should be HTTP accessible.
I don't want to get into the business of managing the update site
repository
"by hand". Ideally a developer should be able to create an
update-site type
project and when she builds it (mvn deploy), the update site ends up
at the
"right" place.
I'm using Nexus for my Maven group repository and I'm wondering whether
there's
a way to let Nexus handle this problem.
I guess overall I'm struggling with the different way Maven and
Eclipse do
things with respect to artifact storage. We talked about this briefly
in the
past.
What would you recommend?
Regards,
-Max
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
