At high level, I think we need to make sure roundtrip between build and
artifact repository works in Tycho as smoothly as it does in plain
Maven. Builds should just "see" new artifacts available from
local/remove repositories.
I also think there should be an easy way to present build results (or
results from multiple related builds) as p2 repository and/or
installable app for testing and production use.
I don't think actual repository format is too important, but I suspect
we'll end up supporting both maven and p2 at least at some level.
There are also related usage scenarios outside traditional scope of
build system, like for example target platform management in PDE. I
think good end-to-end solution should include these too.
I plan to elaborate these ideas in more details in next few days, when
we announce new mailing list dedicated to Tycho and OSGi development
with Maven in general.
Both Update Site and RCP app packaging mojos already pull needed
artifacts from Maven repositories, but this requires properly configured
dependencyManagement (quite tedious to setup and maintain).
--
Regards,
Igor
Max Spring wrote:
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
