Q for Eclipse has been evolving during the past months and adding new features each time. I would say that the most remarkable features came from the community... so I would like to use the community knowledge and imagination to ask:
What features would you like to see in q4e 1.0.0?
There's only one condition: Make sure your feature is not already implemented in the 0.7.0 development branch[1].
[1] New and Noteworthy in 0.7.0 (work in progress): http:// code.google.com/p/q4e/wiki/New_in_0_7_0 -- Abel Muiño Vizcaino - http://ramblingabout.wordpress.com
> Q for Eclipse has been evolving during the past months and adding new > features each time. I would say that the most remarkable features came from > the community... so I would like to use the community knowledge and > imagination to ask:
> What features would you like to see in q4e 1.0.0?
> There's only one condition: Make sure your feature is not already > implemented in the 0.7.0 development branch[1].
I'd love to see integration with the maven osgi plugin and some way to integrate pom.xml and plugin.xml/manifest.mf. Also, the ability to depend on eclipse plugins from a maven-like repository (or treat your eclipse install as a maven repository). The problem there is although most of the version information is in the jar for OSGi, it's doesn't quite match Maven. However, it would be nice if I could make use of all tha amazing features of maven/q4e when developing RCP apps.
On Thu, May 8, 2008 at 9:51 PM, Marcelo Alcantara <mar...@gmail.com> wrote:
> Hi Abel,
> I woud like to see some integration between Maven and Eclipse RCP/Plugins.
> My 2 cents.
> Marcelo
> On Thu, May 8, 2008 at 7:40 PM, Abel Muiño Vizcaino <amu...@gmail.com> > wrote: > > Hi everyone!
> > Q for Eclipse has been evolving during the past months and adding new > > features each time. I would say that the most remarkable features came > from > > the community... so I would like to use the community knowledge and > > imagination to ask:
> > What features would you like to see in q4e 1.0.0?
> > There's only one condition: Make sure your feature is not already > > implemented in the 0.7.0 development branch[1].
On Fri, May 9, 2008 at 10:07 AM, Josh Suereth <joshua.suer...@gmail.com> wrote: > I second that opinion.
> I'd love to see integration with the maven osgi plugin and some way to > integrate pom.xml and plugin.xml/manifest.mf. Also, the ability to depend > on eclipse plugins from a maven-like repository (or treat your eclipse > install as a maven repository). The problem there is although most of the > version information is in the jar for OSGi, it's doesn't quite match Maven. > However, it would be nice if I could make use of all tha amazing features of > maven/q4e when developing RCP apps.
> -Josh
> On Thu, May 8, 2008 at 9:51 PM, Marcelo Alcantara <mar...@gmail.com> wrote:
>> Hi Abel,
>> I woud like to see some integration between Maven and Eclipse RCP/Plugins.
>> My 2 cents.
>> Marcelo
>> On Thu, May 8, 2008 at 7:40 PM, Abel Muiño Vizcaino <amu...@gmail.com> >> wrote: >> > Hi everyone!
>> > Q for Eclipse has been evolving during the past months and adding new >> > features each time. I would say that the most remarkable features came >> > from >> > the community... so I would like to use the community knowledge and >> > imagination to ask:
>> > What features would you like to see in q4e 1.0.0?
>> > There's only one condition: Make sure your feature is not already >> > implemented in the 0.7.0 development branch[1].
Mine is just simple and easy. I would like to see keyboard shortcuts on commonly used stuffs to be implemented in q4e. Developers are more on keyboards rather than on mouse for faster development. I think it's convenient and faster for developers to just press a shortcut key in executing a maven goal rather than going to maven menu and choose.
erle mantos wrote: > For v1.0.0, I would love to see our artifact search integrated with > repository managers > like archiva, etc ..
> Also, the form-based POM editor ala Manifest editor of eclipse.
> On Fri, May 9, 2008 at 10:07 AM, Josh Suereth <joshua.suer...@gmail.com> wrote:
>> I second that opinion.
>> I'd love to see integration with the maven osgi plugin and some way to >> integrate pom.xml and plugin.xml/manifest.mf. Also, the ability to depend >> on eclipse plugins from a maven-like repository (or treat your eclipse >> install as a maven repository). The problem there is although most of the >> version information is in the jar for OSGi, it's doesn't quite match Maven. >> However, it would be nice if I could make use of all tha amazing features of >> maven/q4e when developing RCP apps.
>> -Josh
>> On Thu, May 8, 2008 at 9:51 PM, Marcelo Alcantara <mar...@gmail.com> wrote:
>>> Hi Abel,
>>> I woud like to see some integration between Maven and Eclipse RCP/Plugins.
>>> My 2 cents.
>>> Marcelo
>>> On Thu, May 8, 2008 at 7:40 PM, Abel Muiño Vizcaino <amu...@gmail.com> >>> wrote:
>>>> Hi everyone!
>>>> Q for Eclipse has been evolving during the past months and adding new >>>> features each time. I would say that the most remarkable features came >>>> from >>>> the community... so I would like to use the community knowledge and >>>> imagination to ask:
>>>> What features would you like to see in q4e 1.0.0?
>>>> There's only one condition: Make sure your feature is not already >>>> implemented in the 0.7.0 development branch[1].
As long as mvn clean != Project -> Clean, I'd like to see 'clean' on the context menu. Project -> Clean seems to clean only classes and test-classes. In the case of war and ear packaging, they use build directories which do not get cleaned. So if a dependency or some file is removed, it still exists in the build directory and will get repackaged. A proper clean has to be run by going to execute goal.
-- Robert Dale
On Thu, May 8, 2008 at 6:40 PM, Abel Muiño Vizcaino <amu...@gmail.com> wrote:
> Hi everyone! > Q for Eclipse has been evolving during the past months and adding new > features each time. I would say that the most remarkable features came from > the community... so I would like to use the community knowledge and > imagination to ask: > What features would you like to see in q4e 1.0.0? > There's only one condition: Make sure your feature is not already > implemented in the 0.7.0 development branch[1]. > [1] New and Noteworthy in 0.7.0 (work in > progress): http://code.google.com/p/q4e/wiki/New_in_0_7_0 > -- > Abel Muiño Vizcaino - http://ramblingabout.wordpress.com
* Search integrated with Nexus
* Integration of some commonly used eclipse plugins on project import/
update: checkstyle-cs, PMD, findbugs, cobertura, etc. Maybe as
optional extensions, just like the dependency viewer.
* Maven suggestions also for site.xml files (for skin selection)
* wysiwyg editor for apt documents :-D
> What features would you like to see in q4e 1.0.0?
Being able to import a multimodule project in a single eclipse
project.
I know that this could have issues when there are weird dependencies
in the modules and also that it won't provide good isolation between
the modules, but I find *very* annoying when I checkout code I use for
reference and not for developing to have to allocate dozen projects to
it and not be able to use a single project like I do with m2eclipse.
This is the only motivation I keep using both q4e and m2eclipse at the
same time.
If that's mainly for having code reference, why is the source attachment for dependencies not good enough for your needs?
On Fri, May 9, 2008 at 6:27 PM, Stefano Bagnara <stefano.bagn...@gmail.com> wrote:
> > What features would you like to see in q4e 1.0.0?
> Being able to import a multimodule project in a single eclipse > project. > I know that this could have issues when there are weird dependencies > in the modules and also that it won't provide good isolation between > the modules, but I find *very* annoying when I checkout code I use for > reference and not for developing to have to allocate dozen projects to > it and not be able to use a single project like I do with m2eclipse.
> This is the only motivation I keep using both q4e and m2eclipse at the > same time.
On May 9, 6:36 pm, "Abel Muiño" <amu...@gmail.com> wrote:
> If that's mainly for having code reference, why is the source attachment for
> dependencies not good enough for your needs?
Mainly is not always... sometimes I find bugs in code I depend upon
and I need a smart way to change some code and to run my tests.
I find it frustrating to have to import projects having 50 sub modules
as 50 separate projects in eclipse just because I have to understand
where a bug can be, add some logs to a third party project and run my
own project tests to see what happens, and reiterate this.
E.g: apache camel have 46 modules only for its components, activemq 25
modules. They are dependencies for me, I'm not a developer, but I
often need to debug them. It is MUCH easier to use m2eclipse than q4e
for my workflow.
With m2eclipse I simply checkout the project from my svn view, right
click on the project "enable "maven 2" => "Enable" and the "Update
source folder" and in few minutes everything is ready to be run. one
click I close it, one click I open it. With q4e this is a PITA, maybe
it's me not understanding well q4e multiproject import.
OTOH I really like q4e for single module projects or for my main
projects where I'm fine with 1 project for each module.
just as a suggestion, it's not the solution you're looking for but may help. If debugging you find the code that you need to change you can click the "Link with Editor" in the "Package Explorer" view and that will tell you which jar (module) the code is in, and then you only need to checkout that portion. Other option to not even having to checkout is creating the classes in your project with same name and package that in the library and Eclipse will pick them up first because the order in the classpath
> On May 9, 6:36 pm, "Abel Muiño" <amu...@gmail.com> wrote: > > If that's mainly for having code reference, why is the source attachment for > > dependencies not good enough for your needs?
> Mainly is not always... sometimes I find bugs in code I depend upon > and I need a smart way to change some code and to run my tests. > I find it frustrating to have to import projects having 50 sub modules > as 50 separate projects in eclipse just because I have to understand > where a bug can be, add some logs to a third party project and run my > own project tests to see what happens, and reiterate this.
> E.g: apache camel have 46 modules only for its components, activemq 25 > modules. They are dependencies for me, I'm not a developer, but I > often need to debug them. It is MUCH easier to use m2eclipse than q4e > for my workflow.
> With m2eclipse I simply checkout the project from my svn view, right > click on the project "enable "maven 2" => "Enable" and the "Update > source folder" and in few minutes everything is ready to be run. one > click I close it, one click I open it. With q4e this is a PITA, maybe > it's me not understanding well q4e multiproject import. > OTOH I really like q4e for single module projects or for my main > projects where I'm fine with 1 project for each module.
-- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
> I woud like to see some integration between Maven and Eclipse RCP/ > Plugins.
> My 2 cents.
> Marcelo
> On Thu, May 8, 2008 at 7:40 PM, Abel Muiño Vizcaino > <amu...@gmail.com> wrote: >> Hi everyone!
>> Q for Eclipse has been evolving during the past months and adding new >> features each time. I would say that the most remarkable features >> came from >> the community... so I would like to use the community knowledge and >> imagination to ask:
>> What features would you like to see in q4e 1.0.0?
>> There's only one condition: Make sure your feature is not already >> implemented in the 0.7.0 development branch[1].
This idea of resolving maven artifacts to eclipse bundles is certainly interesting. It would be a challenge to properly resolve the dependencies (specially when using packages instead of bundles).
I don't know if that would be doable in the near future (looks more like a research project), but I think that eclipse bundles had been uploaded to the maven repository already. Also, there are some maven plug-ins for OSGi development that could be used for building eclipse plug-ins with maven.
So, some of the pieces are there already. Could you provide examples of what kind of features you'll want to use, and how, to develop RCP apps with q4e and maven?
> I'd love to see integration with the maven osgi plugin and some way > to integrate pom.xml and plugin.xml/manifest.mf. Also, the ability > to depend on eclipse plugins from a maven-like repository (or treat > your eclipse install as a maven repository). The problem there is > although most of the version information is in the jar for OSGi, > it's doesn't quite match Maven. However, it would be nice if I > could make use of all tha amazing features of maven/q4e when > developing RCP apps.
> -Josh
> On Thu, May 8, 2008 at 9:51 PM, Marcelo Alcantara > <mar...@gmail.com> wrote:
> Hi Abel,
> I woud like to see some integration between Maven and Eclipse RCP/ > Plugins.
> My 2 cents.
> Marcelo
> On Thu, May 8, 2008 at 7:40 PM, Abel Muiño Vizcaino > <amu...@gmail.com> wrote: > > Hi everyone!
> > Q for Eclipse has been evolving during the past months and adding > new > > features each time. I would say that the most remarkable features > came from > > the community... so I would like to use the community knowledge and > > imagination to ask:
> > What features would you like to see in q4e 1.0.0?
> > There's only one condition: Make sure your feature is not already > > implemented in the 0.7.0 development branch[1].
I think it should be easy to mvn clean on project clean (we might even be able to do it in both directions, if that makes any sense). But I couldn't find any open issue for this. -- Abel Muiño Vizcaino - http://ramblingabout.wordpress.com
> As long as mvn clean != Project -> Clean, I'd like to see 'clean' on > the context menu. Project -> Clean seems to clean only classes and > test-classes. In the case of war and ear packaging, they use build > directories which do not get cleaned. So if a dependency or some file > is removed, it still exists in the build directory and will get > repackaged. A proper clean has to be run by going to execute goal.
> -- > Robert Dale
> On Thu, May 8, 2008 at 6:40 PM, Abel Muiño Vizcaino > <amu...@gmail.com> wrote: >> Hi everyone! >> Q for Eclipse has been evolving during the past months and adding new >> features each time. I would say that the most remarkable features >> came from >> the community... so I would like to use the community knowledge and >> imagination to ask: >> What features would you like to see in q4e 1.0.0? >> There's only one condition: Make sure your feature is not already >> implemented in the 0.7.0 development branch[1]. >> [1] New and Noteworthy in 0.7.0 (work in >> progress): http://code.google.com/p/q4e/wiki/New_in_0_7_0 >> -- >> Abel Muiño Vizcaino - http://ramblingabout.wordpress.com
El 09/05/2008, a las 17:49, Rodrigo Ruiz escribió:
> Hi all,
> Here are my two cents:
> * Search integrated with Nexus
Closer that you think. The open search framework on the 0.7.0 can read nexus indexes, and (by default) downloads the one on the central repo. It is not yet integrated with every search feature, but we're on it.
> * Integration of some commonly used eclipse plugins on project import/ > update: checkstyle-cs, PMD, findbugs, cobertura, etc. Maybe as > optional extensions, just like the dependency viewer.
I would ask for more information here... what do you mean by "on project import/update". What kind of integration? (those tools already provide they own eclipse plug-in)
> * Maven suggestions also for site.xml files (for skin selection) > * wysiwyg editor for apt documents :-D
BTW: There's a similar topic on the IAM newsgroup. However, releasing version 1.0.0 of an eclipse plug-in would mean that we've graduated from the incubator, which can not happen until (at least) Eclipse 3.5 (3.4 is coming out in a few months). So you can use your imagination... big time.
> just as a suggestion, it's not the solution you're looking for but > may help. > If debugging you find the code that you need to change you can click > the "Link with Editor" in the "Package Explorer" view and that will > tell you which jar (module) the code is in, and then you only need to > checkout that portion. > Other option to not even having to checkout is creating the classes in > your project with same name and package that in the library and > Eclipse will pick them up first because the order in the classpath
> On Fri, May 9, 2008 at 10:45 AM, Stefano Bagnara > <stefano.bagn...@gmail.com> wrote:
>> On May 9, 6:36 pm, "Abel Muiño" <amu...@gmail.com> wrote: >>> If that's mainly for having code reference, why is the source >>> attachment for >>> dependencies not good enough for your needs?
>> Mainly is not always... sometimes I find bugs in code I depend upon >> and I need a smart way to change some code and to run my tests. >> I find it frustrating to have to import projects having 50 sub >> modules >> as 50 separate projects in eclipse just because I have to understand >> where a bug can be, add some logs to a third party project and >> run my >> own project tests to see what happens, and reiterate this.
>> E.g: apache camel have 46 modules only for its components, >> activemq 25 >> modules. They are dependencies for me, I'm not a developer, but I >> often need to debug them. It is MUCH easier to use m2eclipse than >> q4e >> for my workflow.
>> With m2eclipse I simply checkout the project from my svn view, right >> click on the project "enable "maven 2" => "Enable" and the "Update >> source folder" and in few minutes everything is ready to be run. one >> click I close it, one click I open it. With q4e this is a PITA, >> maybe >> it's me not understanding well q4e multiproject import. >> OTOH I really like q4e for single module projects or for my main >> projects where I'm fine with 1 project for each module.
> -- > I could give you my word as a Spaniard. > No good. I've known too many Spaniards. > -- The Princess Bride
User menu additions
Currently you can run any goal by selecting the Execute Goal menu
item. It would be nice for the standard lifecycle goals to be
available for selection here instead of having to know them and type
the goal name correctly. Also, instead of having to type a goal (and
possibly related properties) each time it would be nice to be able to
save user-assigned menu items to rerun goals.
On May 9, 2:20 pm, Abel Muiño Vizcaino <amu...@gmail.com> wrote:
> BTW: There's a similar topic on the IAM newsgroup. However, releasing
> version 1.0.0 of an eclipse plug-in would mean that we've graduated
> from the incubator, which can not happen until (at least) Eclipse 3.5
> (3.4 is coming out in a few months). So you can use your
> imagination... big time.
> El 09/05/2008, a las 21:03, Carlos Sanchez escribió:
> > just as a suggestion, it's not the solution you're looking for but
> > may help.
> > If debugging you find the code that you need to change you can click
> > the "Link with Editor" in the "Package Explorer" view and that will
> > tell you which jar (module) the code is in, and then you only need to
> > checkout that portion.
> > Other option to not even having to checkout is creating the classes in
> > your project with same name and package that in the library and
> > Eclipse will pick them up first because the order in the classpath
> > On Fri, May 9, 2008 at 10:45 AM, Stefano Bagnara
> > <stefano.bagn...@gmail.com> wrote:
> >> On May 9, 6:36 pm, "Abel Muiño" <amu...@gmail.com> wrote:
> >>> If that's mainly for having code reference, why is the source
> >>> attachment for
> >>> dependencies not good enough for your needs?
> >> Mainly is not always... sometimes I find bugs in code I depend upon
> >> and I need a smart way to change some code and to run my tests.
> >> I find it frustrating to have to import projects having 50 sub
> >> modules
> >> as 50 separate projects in eclipse just because I have to understand
> >> where a bug can be, add some logs to a third party project and
> >> run my
> >> own project tests to see what happens, and reiterate this.
> >> E.g: apache camel have 46 modules only for its components,
> >> activemq 25
> >> modules. They are dependencies for me, I'm not a developer, but I
> >> often need to debug them. It is MUCH easier to use m2eclipse than
> >> q4e
> >> for my workflow.
> >> With m2eclipse I simply checkout the project from my svn view, right
> >> click on the project "enable "maven 2" => "Enable" and the "Update
> >> source folder" and in few minutes everything is ready to be run. one
> >> click I close it, one click I open it. With q4e this is a PITA,
> >> maybe
> >> it's me not understanding well q4e multiproject import.
> >> OTOH I really like q4e for single module projects or for my main
> >> projects where I'm fine with 1 project for each module.
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> > -- The Princess Bride
> Also, instead of having to type a goal (and > possibly related properties) each time it would be nice to be able to > save user-assigned menu items to rerun goals.
This is already possible if you create a Run configuration (Run > Open Run dialog... > Maven2 > (right-click) > New) which is probably the "eclipse way" of doing it. You can then mark this configuration as a Favorite so it is always on the Run button menu.
I feel like the menu item is kind of re-implementing this, so I'm more on removing it than enhancing it... but you (the community) will tell us what to do!
I tried creating a run configuration which specified project 'A' and
then I was able to select from the Run As Maven contextual menu and
select a run configuration for project 'B' -- a new launch
configuration was automatically created for project 'B' with the same
goal.
Based on the capability mentioned above it seems like the contextual
menu does add some additional capability so I would vote to keep it.
Also I still think that it would be nice for the standard lifecycle
goals to be available for selection here instead of having to know
them and type the goal name correctly.
On May 10, 12:37 am, Abel Muiño Vizcaino <amu...@gmail.com> wrote:
> > Also, instead of having to type a goal (and
> > possibly related properties) each time it would be nice to be able to
> > save user-assigned menu items to rerun goals.
> This is already possible if you create a Run configuration (Run >
> Open Run dialog... > Maven2 > (right-click) > New) which is probably
> the "eclipse way" of doing it. You can then mark this configuration
> as a Favorite so it is always on the Run button menu.
> I feel like the menu item is kind of re-implementing this, so I'm
> more on removing it than enhancing it... but you (the community) will
> tell us what to do!
> El 09/05/2008, a las 17:49, Rodrigo Ruiz escribió:
> > Hi all,
> > Here are my two cents:
> > * Search integrated with Nexus
> Closer that you think. The open search framework on the 0.7.0 can
> read nexus indexes, and (by default) downloads the one on the central
> repo. It is not yet integrated with every search feature, but we're
> on it.
Cool! It's good to know :-)
> > * Integration of some commonly used eclipse plugins on project import/
> > update: checkstyle-cs, PMD, findbugs, cobertura, etc. Maybe as
> > optional extensions, just like the dependency viewer.
> I would ask for more information here... what do you mean by "on
> project import/update". What kind of integration? (those tools
> already provide they own eclipse plug-in)
I ment integration with those eclipse plug-ins. For example, every
time I import a Maven project into my Eclipse, I have to manually edit
the project properties for setting the checkstyle plugin
configuration. It would be great if the importer could use the
information in pom.xml and configure the resulting project plugin
details accordingly.
> > * Maven suggestions also for site.xml files (for skin selection)
> > * wysiwyg editor for apt documents :-D
This proposed feature is in keeping with the goal of providing a more
visual nature for Maven users in Eclipse.
Similar to View Dependencies, this feature would produce a graphical
representation of the relationship between modules in a multi-module
build. This feature would help developers to quickly understand the
relationships involved in a multi-module build (dependency,
inheritance and aggregation).
For an example of the general nature of the graphical representation,
please consult the article referenced below, which summarizes the
graphical notation in Figure 7 -- A relationship graph. The graph
includes relationships for 'depends on', 'inherits from' and
'aggregates'.
Note that this graph would only need to show module dependencies,
since the existing View Dependencies already has addressed the general
artifact dependency graph.
This feature would be particularly useful for someone examining a
multi-module project build produced by others, because it would
quickly summarize all of the relationships in a single graphical view.
On May 11, 12:01 am, Rodrigo Ruiz <rodrigo.ruiz.agu...@gmail.com>
wrote:
> On May 9, 10:41 pm, Abel Muiño Vizcaino <amu...@gmail.com> wrote:
> > Hi!
> > El 09/05/2008, a las 17:49, Rodrigo Ruiz escribió:
> > > Hi all,
> > > Here are my two cents:
> > > * Search integrated with Nexus
> > Closer that you think. The open search framework on the 0.7.0 can
> > read nexus indexes, and (by default) downloads the one on the central
> > repo. It is not yet integrated with every search feature, but we're
> > on it.
> Cool! It's good to know :-)
> > > * Integration of some commonly used eclipse plugins on project import/
> > > update: checkstyle-cs, PMD, findbugs, cobertura, etc. Maybe as
> > > optional extensions, just like the dependency viewer.
> > I would ask for more information here... what do you mean by "on
> > project import/update". What kind of integration? (those tools
> > already provide they own eclipse plug-in)
> I ment integration with those eclipse plug-ins. For example, every
> time I import a Maven project into my Eclipse, I have to manually edit
> the project properties for setting the checkstyle plugin
> configuration. It would be great if the importer could use the
> information in pom.xml and configure the resulting project plugin
> details accordingly.
> > > * Maven suggestions also for site.xml files (for skin selection)
> > > * wysiwyg editor for apt documents :-D
Here is another list of issues related to the multimodule import:
- When I run refactorings involving minor changes in all of the
modules-projects Eclipse will do 1 commit for each module. So, first,
it seems my commit is no more atomic.
- When I move/copy code between different modules-project eclipse does
not correctly handle the svn cp/rm stuff to preserve my history.
- Opening and closing my 20 modules project imported with q4e takes
almost 5 minutes (it keeps updating classpath and similar things)
while the same on m2eclipse take 10 seconds.
- Running the import of a multimodule already on my disk use the
module artifactId as eclipse project identifier. Sometimes artifactId
are identical in different projects. I found no way to tell q4e to use
groupId+artifactId or to use a prefix when importing a multimodule
project.
any check option to eliminate project relations. If I'm working on a
project development I want to take into account only this project
souce classes, and not to have other projects related. The other
project classes used by my project should be imported by a maven
dependency (I guess this is the sense of maven!!!). I think it's a big
mistake to allow other project to be related. If any one wants it,
maybe should be checked as an option, but by default it should be
erased!
On 9 mayo, 00:40, Abel Muiño Vizcaino <amu...@gmail.com> wrote:
> Q for Eclipse has been evolving during the past months and adding new
> features each time. I would say that the most remarkable features
> came from the community... so I would like to use the community
> knowledge and imagination to ask:
> What features would you like to see in q4e 1.0.0?
> There's only one condition: Make sure your feature is not already
> implemented in the 0.7.0 development branch[1].
> [1] New and Noteworthy in 0.7.0 (work in progress): http://
> code.google.com/p/q4e/wiki/New_in_0_7_0
> --
> Abel Muiño Vizcaino -http://ramblingabout.wordpress.com
More as a comment than a specific feature, is simply to try to have Q4E be as simple as possible when initially installed for Maven integration with Eclipse, with the primary piece being the dependency management.
To be more specific, if the default install of the Q4E plugin is as non-invasive and do it's best to not 'lock up eclipse' (i.e. the repo indexing and occasionally dependency resolution), this will make it easier to adopt and can use more advanced features when required/explicitly enabled -- this will also make it more clear to un-educated users that you have to turn on a specific feature that may hurt your IDE performance working on a project; they know the impact instead of just complaining about the plugin ;-)
> On 9 mayo, 00:40, Abel Muiño Vizcaino > <amu...@gmail.com> wrote: > > Hi everyone!
> > Q for Eclipse has been evolving during the past > months and adding new > > features each time. I would say that the most > remarkable features > > came from the community... so I would like to use > the community > > knowledge and imagination to ask:
> > What features would you like to see in q4e 1.0.0?
> > There's only one condition: Make sure your feature > is not already > > implemented in the 0.7.0 development branch[1].
> > [1] New and Noteworthy in 0.7.0 (work in > progress): http:// > > code.google.com/p/q4e/wiki/New_in_0_7_0 > > -- > > Abel Muiño Vizcaino > -http://ramblingabout.wordpress.com
I'd rather diagnose and fix the causes of any complains than avoid them by disabling functionality.
Regarding the "project relations", they are dependencies resolved from the workspace. That essentially saves you the extra step of "mvn install" a project before you can use/test any change made to it.
> any check option to eliminate project relations. If I'm working on a > project development I want to take into account only this project > souce classes, and not to have other projects related. The other > project classes used by my project should be imported by a maven > dependency (I guess this is the sense of maven!!!). I think it's a big > mistake to allow other project to be related. If any one wants it, > maybe should be checked as an option, but by default it should be > erased!
> On 9 mayo, 00:40, Abel Muiño Vizcaino <amu...@gmail.com> wrote: >> Hi everyone!
>> Q for Eclipse has been evolving during the past months and adding new >> features each time. I would say that the most remarkable features >> came from the community... so I would like to use the community >> knowledge and imagination to ask:
>> What features would you like to see in q4e 1.0.0?
>> There's only one condition: Make sure your feature is not already >> implemented in the 0.7.0 development branch[1].
>> [1] New and Noteworthy in 0.7.0 (work in progress): http:// >> code.google.com/p/q4e/wiki/New_in_0_7_0 >> -- >> Abel Muiño Vizcaino -http://ramblingabout.wordpress.com
