Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [b3-dev] try not to mirror antlr


Hi, this bug fixing is quite slow, can I fix
https://bugs.eclipse.org/bugs/show_bug.cgi?id=338405 on my own?

The reason this bug has somewhat low priority is that it only affects
legacy sites and therefore very few users get exposed to it.

Can you please explain why only legacy sites are affected? Then, maybe its better to get in contact with the ANTLR people, telling them they should rebuild their update site (http://antlreclipse.sourceforge.net/updates/).


Does anybody know a concept of how to configure a workspace
considering a set of checked out SVN projects using a b3 aggregator
model? I use b3 to configure all plugin dependencies for an Eclipse
developer IDE, however if the developer can checked out the SVN
projects automatically by choosing some categories of interest from
the update site, this would be much time-saving for him!

The b3 aggregator deals solely with p2 or Maven artifacts. Not sure I
follow your line of reasoning when you talk about the b3 in concjunction
with SVN. Can you please elaborate?

When a Eclipse developer has to configure his Eclipse to get ready for developing, (1) he first has to install a bunch of upate sites required by the project, and after this (2) he often checks out a bunch of SVN projects where the code resides, maybe from different SVN repositories.

With b3, (1) can be automated very well, however (2) is not automated by now. It would be nice, if not only p2 artifacts can be added and grouped with b3, but also SVN projects within a category. So you could put SVN projects (actually only the SVN URLs) into a category, and maybe the category also contains all required p2 dependencies required for the SVN projects to compile.

One way to do it is maybe to mark an added feature with a boolean property "asSource", so the feature is not installed into the Eclipse IDE but actually the SVN source projects are imported. A feature is made up of a bunch of plugins, so installing such a feature marked with "asSource" imports all those plugins from SVN repositoris into the workspace of the developer. b3 would need to know where to find the SVN location of a plugin, this could be done by defining a set of SVN parent directory URLs, and b3 checks each parent directory if the project is contained in the directory (assuming the plugin name has the same name as the directoy name of the SVN project, which belongs to the best pratices). Instead of using a feature, one could also use a product maybe.

Ok, actually p2 must implement this logic, however if this is not possible, have you any idea how to automatic the checking out of SVN projects?

Cheers,
Joerg


Back to the top